karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Sun, 13 Sep 2015 17:13:00 GMT
Hi Christian,

Workload is one thing, multi-dependencies/pom/etc is something.

In the annotations, even if the workload is the same, it's the kind of 
annotations. The purpose is to provide more high level, use case centric 
annotations, more than low level technical one.

I agree that we could extend the maven-blueprint-plugin, but I would 
prefer to keep it more high level and decoupled from the underlying 
technology involved.

karaf-boot purpose is to be straight forward and avoid the "big mess & 
soup about what should I use, what the version, etc".

I'm still convince that at least a BoM provided by karaf-boot is 
interesting.

I'm also still think that an abstract Karaf oriented is valid.

Regards
JB

On 09/13/2015 06:38 PM, Christian Schneider wrote:
> Hi JB,
>
> some comments inline.
>
> Am 13.09.2015 um 17:21 schrieb Jean-Baptiste Onofré:
>> Hi Milen,
>>
>> First, let's take spring-starter-embed out of the picture (it's the
>> part to embed Karaf and applications in a big jar file ready to execute).
>> Let's focus on the pure dev path.
>>
>> Let me take two use cases:
>>
>> 1. Very Simple
>> In this example, you have one interface, one bean (business code), you
>> want to expose the bean as a service.
>> You can:
>> 1.1. Use native OSGi:
>>     - Effort: in addition of the business code, you have to write the
>> Activator, knowing the "OSGi API", dealing with the service
>> registration lifecycle. In addition, you have to prepare a Maven
>> pom.xml with bundle as packaging and dealing with maven-bundle-plugin.
>>     - Workload: I evaluate that your business code is only 50% of the
>> workload, as you need to write the Activator and the pom.
> I would never recommend to use native OSGi for business code as it is
> too error prone. So lets simply leave out this one.
>> 1.2. Use blueprint:
>>     - Effort: in addition of the business code, you have to write
>> OSGI-INF/blueprint/your.xml blueprint descriptor. So, instead of the
>> "OSGi API", you have to know the blueprint syntax. The pom.xml is the
>> same as in 1.1.
>>     - Workload: I evaluate that your business code is 55-60% of the
>> workload. You need to write the blueprint XML, but if you have
>> multiple beans it's probably easier than an activator (not sure ;)).
> Alternative: Use CDI annotations and maven blueprint plugin. This should
> result in similar percentages to SCR. The advantage is that the CDI
> annotations are well known and standardized. OSGi services are covered
> with pax cdi annotations.1.3. Use scr annotations:
>>     - Effort: you use scr annotations directly in your bean
>> (@Component, @Activate, etc). The pom.xml is the same as the
>> maven-bundle-plugin generate the components XML for you. It requires
>> that your know the SCR annotations (low level), and add required
>> dependencies in the pom.xml
>>     - Workload: your business code is 80% of the workload, 20% is
>> about the annotations and pom.xml
> I agree with this. Though percentages will be even better in typical
> multi module projects as you can define the maven bundle plugin once in
> the parent.
>
>> 1.4. Use karaf-boot:
>>     - Effort: you have the choice between the karaf-boot annotations
>> (high level) or the scr annotations (low level). In the pom.xml, you
>> just have to add a dependency to karaf-boot-starter (for karaf-boot
>> annotations) or karaf-boot-starter-scr (for scr annotations). The
>> karaf-boot-starter* are BoM describing all that you need, including
>> scr dependencies.
>>     - Workload: your business code is 85% of the workload, 15% about
>> the annotations and pom.xml. The gap of 5% compared to 1.3 is due to
>> the usage of karaf-boot-starter* that brings all the dependencies for
>> you (you don't have to figure out all dependencies set, etc in your
>> pom.xml).
> As you describe yourself the percentage is not much better than scr or
> blueprint approach with annotations. So I think it is clearly not worth
> introducing a proprietary framework for this little advantage.
>>
>> So, on this first use case, scr and karaf-good are probably the
>> easiest way to go.
>>
>> 2. JPA (the same can be applied to JTA, REST, SOAP, etc)
>> In this example, you want to expose a service dealing with JPA/JTA.
>> You have an @Entity POJO, and a DAO using JPA and the entity.
>> You can:
>> 2.1. Use native OSGi:
>>     - Effort: you have to create the Activator. The Activator can
>> create an EntityManager or retrieve one as a service. You have to
>> create the META-INF/persistence.xml. You have to call the
>> maven-budle-plugin in your pom.xml, without forget to define the
>> <META-INF/> element.
>>     - Workload: your business code is about 40% of the workload, bunch
>> of code has to be written in the activator. You also have to create
>> the META-INF/persistence.xml.
> Again lets jut leave it out.
>> 2.2. Use blueprint:
>>     - Effort: with latest Aries Blueprint versions, you have to create
>> a blueprint XML with <jpa:enable/> element and defining
>> beans/services. You still have to write the persistence.xml and update
>> the pom.xml
>>     - Workload: your business code is about 60% of the workload
> Like in CDI annotations with blueprint.  Additional you can easily use
> JPA and transactions with pure JTA and JPA annotations. So it is all
> standardized, well known. The annotations are almost exactly like for
> pax cdi. So as soon as it is matured you can siwtch to it easily.
>
> 2.2. Use SCR:
>> Unfortunately, we don't have direct support of JPA (or other
>> enterprise stuff) in SCR.
> The new Aries JPA supports closure based jpa and jta support which is
> almost as nice as annotation based.
> I hope we can persuade the SCR people over time to allow interceptors so
> we can close the gap.
>> 2.3. Use karaf-boot:
>>     - Effort: your just add @jpa(provider="openjpa",dataSource="my")
>> on the your DAO class. karaf-boot will create the persistence.xml for
>> you (and the blueprint descriptor for now).
>>     - Workload: your business code is 95% of the workload, 5% is just
>> to define karaf-boot-starter-jpa dependency in your pom.xml.
> I think the @jpa annotation is just syntactic sugar. It only saves the
> persistence.xml which is a well known structure  and allows further
> customizations most people need anyway over time.
> I agree that the annotation save a bit xml but as you tpyically can just
> copy it from an example or archetype it is not really relevant.
> When the project grows the fixed xml size will be less and less relevant.
>
>>
>> For instance, for rest service, it could be the same: right now you
>> have to write a blueprint xml with <jaxrs:server/> element (using
>> CXF-RS). karaf-boot-starter-rest will do that for you, using the @rest
>> high level annotation that you can define on your rest class (where
>> you already have the @Path, @GET, etc jax-rs annotations).
> For rest I can imagine using a special annotation. I propose to ot
> include it in karaf though and instead implement it as a plugin to the
> maven-blueprint-plugin.
> As the Aries goal is to support enterprise development in OSGi I think
> it is a better place to put these efforts.
>
> Christian

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message