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 Thu, 10 Sep 2015 16:19:05 GMT
I know. The plugin is a bit invasive: it add it even if you don't use 
persistence and transaction annotations ;)

And again, it's generic and abstracted annotations on top of it.

Today we generate blueprint, maybe tomorrow spring, maybe tomorrow DS, 
but generic level.

Regards
JB

On 09/10/2015 06:16 PM, Christian Schneider wrote:
> I already adapted the maven blueprint plugin on trunk to do this.
> So you can use a project just with annotations and the blueprint for jpa
> 2 and jta 3 is fully generated.
>
> The only thing you still need to create is the persistence.xml. It will
> not have to contain much though.
> So I can see a case where it could make sense to create an annoation
> that controls creation of the persistence.xml.
>
> As this would only replace a simple standardized xml file with a
> proprietary set of java classes and annoations I do not see a good case
> for it.
>
> Instead I could imagine something like spring roo where the user gets
> some tooling to add the jpa dependencies / setup to an existing project.
>
> Christian
>
> Am 10.09.2015 um 18:03 schrieb Giuseppe Gerla:
>> Hi JB
>> just to understand better.
>> Your idea is to introduce annotation to allow the plugin to generate xml
>> automatically.
>> So it seems that for JPA (for example) you will not introduce some other
>> annotation, because if you find some class that has
>> @PersistenceContext you
>> can add following row in the blueprint xml
>>
>> <jpa:enable />
>>
>> and for JTA if you find some class with @Transactional annotation you can
>> add following row in the blueprint xml
>>
>> <tx:enable-annotations />
>>
>>
>> If this is your idea, I agree to extend the Karaf-Boot functionality with
>> JPA and JTA annotation support, otherwise I will prefere to limit it.
>>
>>
>> Regards
>> Giuseppe
>>
>> 2015-09-10 17:46 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>
>>> By the way, we don't duplicate functionality: we just leverage and
>>> generate the resources.
>>>
>>> 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

Mime
View raw message