karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 16:16:26 GMT
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
>>


Mime
View raw message