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 Fri, 11 Sep 2015 06:47:03 GMT
Hi JB,

I'm very sorry but I have to completely disagree on this.
Let me point this out inline


> Generally speaking, I think we are not the best ones to evaluate this
> because we are involved in the "low level", and so we might not see values
> there.
>
>
This might be true for core developers that only work on Karaf, it
certainly doesn't affect me, as my day-job requires me to work with
everything else but OSGi. Therefore I think I'm in the very convenient
position to say: "I know what is missing and I know where the benefits of
Spring-Boot are"
Working on Karaf and Pax Web is just a mere hobby for me, as it doesn't pay
my bills.


> It would be great to have "new developers" feedback (it's where I started
> for karaf-boot actually). That's the key point: think when you are very new
> to Karaf and you have to start.
>
>
see above


> Anyway, my comments inline:
>
>
> On 09/10/2015 11:58 PM, Achim Nierbeck wrote:
>
>> 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.
>>
>
> I agree. With the current annotations (whatever the ones we use, CDI, DS,
> etc):
> - they are very low level, and doesn't provide "key turn" annotations
> - they don't provide enterprise ready annotations
> - depending of the annotations, it's spread on different dependencies and
> packages (not easy for the user)
>
> Basically, a new developer starts on Karaf, it could be lost: a fair
> question is what technology should I use.
>
>
Use CDI it's a standard annotation and can equally be used for Spring or in
a modern Enterprise Server.



> We bring an important flexibility, which is awesome for the advanced users.
>
> But this flexibility means it's not easy to start and choose something: I
> have to learn, prepare my pom.xml accordingly, etc.
>
> The purpose of karaf-boot is not to create new technology, it's just to
> leverage the existing ones, hide it to the developer, and provide a quick
> and easy starter.
>
>

great, and this is the point we need to focus on! Make it easier to develop
a Bundle to run on Karaf.
That's why I might need to elaborate a bit more about my idea of BOMs.
Take for example the spring-boot-log4j-starter bom. If you use that one all
is included to work with log4j logging, one dependency in your POM,
no need to have a Parent.
Same for REST, depending on what people would like to use it can be a
karaf-boot-cxf-jaxrs-starter bom, which contains the dependencies for
working with cxf rest including the feature definition that needs to be
used by karaf.
Here we need something "new", if a feature is present in the POM and we
have the karaf-maven-plugin in use (the only valid point for a Parent POM
to have that as default available) this feature must be used inside the
generated feature as dependency and the karaf-maven-plugin should generate
according to the requirements the dependencies from that feature.


>
>>
>> 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.
>>
>
> I already have karaf:run on one of my branches, but the purpose is
> different. Let's keep the starter out of the picture for now.
>
> A BoM can be materialize as a parent-pom, it's the purpose of the
> karaf-boot-parent.
>
> Maven archetype is good, but it's require to execute the archetype, update
> the project definition before being able to build. Of course, it makes
> sense to provide it.
>
> But, the big advantage of karaf-boot-parent, it's again easy and key turn:
> I'm a new developer, I just inherit from karaf-boot-parent, I just define
> groupId, artifactId, version, I'm ready to go.


I'm sorry but this is a too big cannon you use to shoot on sparrows.
Think minimalistic and modular. With the karaf-boot-*-starter boms we would
achieve something far more modular and closer to what people actually need.
And forgive me for comparing it with spring-boot again, the big benefit of
it is actually those *starter boms.


>
>
>
>>
>> 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.
>>
>
> It's another point, but @rest and karaf-boot-starter address this, using
> profiles and karaf minimal distribution.


here we are inline, a minimalistic distribution based on profiles should
do.


>
>
>
>>
>> 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.
>>
>
> See my previous comment.
>
>
>>
>>
>> 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
>>
>
> You talk about JPA/JTA and I agree. But don't forget high level
> annotations like @jpa(provider = "openjpa", dataSource = "my"), @rest,
> @soap, @jms, etc.
>

all those "high" level annotations are already solve.
Take Jersey or CXF you can use either to solve the @rest or @soap
annotations. We don't need extras here
We should thoroughly look through the ones that are already available with
CDI and make sure we don't re-invent the wheel wrong here.


>
> That's why abstract, high level annotations could make sense.
>


only for the ones missing, yes then it might be helpful, but to my
understanding this should be the last Story in the backlog to have a
quick-and-easy to build environment.


regards, Achim




>
> Regards
> JB
>
>
>
>>
>> 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
>>>
>>>
>>
>>
>>
> --
> 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