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 > -- Matt Sicker <[email protected]>
