Move SpringBoot Forge Addon to Github Forge

[cmoulliard]

The SpringBoot Forge addon is embedded within the devops project, released through Fabric8 Forge project and tight withe Fabric8 dependencies.

In order to make the project more transparent, to release it outside of Fabric8, support it for specific versions of SpringBoot according to the initializr file , add new commands to scaffold code, ... I would like to propose that

• We move this Spring Boot Forge code to a standalone Github project
• We transfert the code to the JBoss Forge github organization (https://github.com/forge)

Tasks

• Create JBoss Forge Spring Boot Addon project - https://github.com/forge/springboot-addon
• Copy code to its new house
• Decouple springboot addon from what is fabric8 devops specific (= Kubernetes client/f8 deps)
• Add test case to use the new Spring Boot Forge Addon

[jstrachan]

I'd be cool with this provided that someone volunteers to do all the work and ensures that the new location gets integrated back nicely into the current fabric8-forge release (& tested to make sure it still works!) so that its included in new fabric8 upstream releases and that the CI / CD / PR is setup nicely (like the rest of fabric8 itself) - so that as new releases are made of the spring boot addon it gets automatically upgraded in fabric8-forge.

We don't want a repeat of where fabric8-forge code is forked to forge and then we're left with a dead fork here!

[cmoulliard]

@jstrachan What do you suggest that we do ? Define list of actions in order to move transparently (without too much frictions) this project ?

[jstrachan]

@cmoulliard if you take responsibility and make sure that you setup the new project to be integrated properly into fabric8-forge, that it still works & that as you release new versions of it the CI / CD does a PR on fabric8-forge I'm happy.

So I take it you're gonna do all this work right?

[cmoulliard]

This is the idea James.

Nevertheless, I'm wondering how we could manage easily what is F8 specific :

Example : the F8 dependencies -> maybe using a parameter that we can pass to the addon to tell that we want to include additional deps. As they are hard coded, we should find a way to specify them & make the solution generic as we could imagine that some deps could be added while they aren't yet available like by example : spring-boot-starter for keycloak, infinispan, ...

I'm not sure that this is the responsibility of the Spring Boot Forge Addon to continue to manage what is specific to DevOps and defined within the AbstractDevOpsCommand. what is your opinion ?

[jstrachan]

We've similar issues in reverse - we need to add dependences upstream that obsidian strips out. We'll need to refactor the code to make things easier to extend for upstream fabric8, fabric8 SaaS and obsidian/forge.

e.g. fabric8-launcher/launchpad-backend#25

we just need to figure out the right hooks to make things reusable and composable

[cmoulliard]

Here are 2 additional pieces of code that we should remove from the Spring Boot Forge Addon

• Camel deps
• Fabric8

[metacosm]

New addon lives at https://github.com/forge/springboot-addon. A decision needs to be taken with respect this issue.