karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup
Date Thu, 17 Dec 2015 16:45:42 GMT
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
>



-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message