karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup
Date Thu, 17 Dec 2015 20:31:36 GMT
Fully agree.

Furthermore, providing bom, parent pom, or whatever it helps, makes sense ;)

Regards
JB

On 12/17/2015 09:27 PM, Matt Sicker wrote:
> Well, anything to help migrating from straight Karaf to karaf-boot would be
> great.
>
> On 17 December 2015 at 14:24, Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
>
>> Hi Matt,
>>
>> we already have maven archetype, but generally speaking I'm not a big fan.
>>
>> Think about karaf boot with gradle, archetype won't help there.
>>
>> Personally, I prefer to start with a blank pom more than an archetype ;)
>>
>> But definitely, we will provide archetypes.
>>
>> Regards
>> JB
>>
>>
>> On 12/17/2015 05:45 PM, Matt Sicker wrote:
>>
>>> Whatever happened to maven archetypes? This could work for this situation
>>> rather well.
>>>
>>> On 17 December 2015 at 04:46, Jean-Baptiste Onofré <jb@nanthrax.net>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> Yes, I agree about the PoC approach, but I think PoC can become a project
>>>> or as least some module can use the "easy" karaf-boot way.
>>>>
>>>> My only concern about copy/paste is that the project bootstrapping is
>>>> long: personally, using archetype or copy paste from a sample pom is fine
>>>> but long, actually longer than just describing couple of dependencies and
>>>> plugin. But it could make sense.
>>>>
>>>> For multi-module, I agree, but I don't see any show stopper: each module
>>>> can use karaf-boot and work together (see the samples of service provider
>>>> and consumer, karaf-boot should really encourage to leverage the service
>>>> approach).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 12/17/2015 11:20 AM, Christian Schneider wrote:
>>>>
>>>> For me the main purpose of karaf boot in unchanged form is to allow
>>>>> people to easily create small proof of concepts.
>>>>> In this stage it normally is no issue that you do not use the company
>>>>> parent pom. You can start easily with karaf boot and bring your poc to
a
>>>>> level where management decides to use karaf.
>>>>>
>>>>> Then at some point you need to transition to a regular project. So you
>>>>> can copy the karaf boot parent, edit it to include your company parent
>>>>> and other changes you might need and use it for your project(s).
>>>>> This transition phase will also happen when you use the blackbox
>>>>> karaf-boot plugin but then it will be a lot harder to adapt it to your
>>>>> needs.
>>>>>
>>>>> Another thing we need to look at is the transition from a single module
>>>>> project to a multi module project. I think it is really great to let
>>>>> people start with a single module/project but to leverage OSGi people
>>>>> will want to build multi module projects at some point. This will either
>>>>> happen during the transition from poc to a regular project or even
>>>>> earlier. So I think we also need to make sure that multi module projects
>>>>> can be built easily. For this case I think
>>>>> it is natural that the set of modules that form you application will
>>>>> have their own parent pom (that of course might depend on a company
>>>>> parent).
>>>>>
>>>>> Christian
>>>>>
>>>>> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
>>>>>
>>>>> Hi Serge,
>>>>>>
>>>>>> It's what I meant by "intrusive": sometime we have to use a company
>>>>>> wide parent pom, no choice. So we can't force the usage of a
>>>>>> karaf-boot parent IMHO.
>>>>>>
>>>>>> That's why, after the earlier discussions on the mailing list, I
did:
>>>>>> - a set of karaf-boot-starter, providing dependencies depending what
>>>>>> you need (rest, jpa, shell, etc). They act as BoM and users just
have
>>>>>> to define in the dependencies set (see the karaf-boot-samples).
>>>>>> - as a BoM doesn't bring plugin (only dependencies), and to simplify
>>>>>> the build/bootstrapping at maximum, I created the
>>>>>> karaf-boot-maven-plugin. This plugin is responsible of scanning the
>>>>>> starters, scanning the sources, and depending of those, build and
>>>>>> possibly bootstrap the project by wrapping other plugins.
>>>>>>
>>>>>> So, we are really in a kind of black box, where processes are hidden:
>>>>>> and it's one of karaf-boot main purpose. However, I got Christian's
>>>>>> point: he's more in the way to not hide as he expects later people
>>>>>> won't use karaf-boot to a more advanced/expert way. So, at that time,
>>>>>> people can "duplicate" what we have in a parent-pom.
>>>>>>
>>>>>> That's why maybe we can provide both:
>>>>>> - I honestly think that "hide way" will match in 80% of the cases,
>>>>>> where people wants to focus on business code and don't care about
the
>>>>>> plumbing. It's the feedback that I got discussing with different
>>>>>> people like Serge, and others (from different background, business,
>>>>>> company).
>>>>>> - However, at least by documentation or parent pom, we have to provide
>>>>>> a way to karaf-boot users to use a very advanced/expert way. I like
>>>>>> Christian's idea to use an extender, it makes sense in some use case.
>>>>>> The profile or feature generation by annotation or starter scanning
is
>>>>>> also interesting IMHO.
>>>>>>
>>>>>> My $0.02 ;)
>>>>>>
>>>>>> 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