Well, anything to help migrating from straight Karaf to karaf-boot would be great.
On 17 December 2015 at 14:24, Jean-Baptiste Onofré <[email protected]> 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é <[email protected]> >> 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é >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <[email protected]>
