Migrate all project to f-m-p v3

[rhuss]

Currently some of the modules have been migrated to fabric8-maven-plugin v3 already, but still quite some are stuck on v2. This can be detected by a marker file uses.fmp2 within the module directory and which is used to switch on / off profiles in the top level pom for the two versions, respectively.

One drawback is that the packages projects which collect resource descriptors from the various other modules work differently for v2 and v3, so a package can only contain resources from modules which uses the same version of f-m-p.

In order to avoid future confusion, all modules should be migrated as fast as possible to v3.

Some ideas from todays chat:

11:23:18]  <ro14nd> +jstrachan: how is gofabric8 using the json/yamls generated by fabric8-devops ? Is it downloading it directly from the Maven Repo ?
[11:23:54]  sabre1041 ([email protected]) joined the channel
[11:24:19]  jnetherton (~jnetherto@2a00:23c4:6680:2600:56ee:75ff:fe31:ecae) left IRC (Quit: Leaving)
[11:24:22]  <+jstrachan>    yeah
[11:25:35]  jnetherton (~jnetherto@2a00:23c4:6680:2600:56ee:75ff:fe31:ecae) joined the channel
[11:27:12]  <ro14nd>    could this be changed to pick it up from within a jar ? this would be the easiest, so we only have to deal with a single jar artefact (where we could put in openshift and kubernertes descriptors).
[11:27:26]  <+jstrachan>    yeah
[11:28:12]  sabre1041 ([email protected]) left IRC (Ping timeout: 240 seconds)
[11:28:24]  <+jstrachan>    at some point I imagine we'd wanna make a kinda helm chart distro too btw; but thats a little ways off I think
[11:28:50]  <+jstrachan>    the main issue is gonna be incrementally moving different projects over to the new jar model as and when we get them implemented; as we've got lots of distros in gofabric8 right now
[11:29:10]  <ro14nd>    cool, I'll raise an issue for gofabric8 for dealing with jars (since I probably can finish it till friday).
[11:29:31]  <+jstrachan>    https://github.com/fabric8io/gofabric8/blob/master/cmds/deploy.go#L61-L74
[11:29:59]  <+jstrachan>    I guess it already unzips the zips - so it might not be too hard really
[11:30:14]  <ro14nd>    yes, the problem now is for 'mixed' packages (v2 and v3) since that doesnt work. Like 'chat-slack' which uses 'hubot-slack' (v3) and 'hubot-notifier' (v2)
[11:30:27]  <+jstrachan>    its just the jars will have different folders to look inside; but shoudn't be too hard to make it work with both and we can over time move to the new approach
[11:30:32]  <+jstrachan>    yeah
[11:30:40]  <+jstrachan>    sooner we move all over to the new f-m-p the better really
[11:31:38]  <ro14nd>    indeed. btw, I added a tag file 'uses.fmp2' to each module which uses fmp2 and then have two different profiles activated based on the existance / absence of this file for f-m-p v2 vs. v3 configuration.
[11:32:00]  <ro14nd>    so we can also easily see, what is still v2.
[11:32:56]  <+jstrachan>    coolio
[11:33:22]  <+jstrachan>    wonder if we need a little tool to help migrate?
[11:33:59]  <+jstrachan>    e.g. take the generated target/kubernetes.yml file and remove the stuff we think we can automate (e..g labels, name, whatnot) and convert to src/main/fabric8/*.yml files?
[11:34:32]  <+jstrachan>    we can then over time manually delete stuff from the src/main/fabric8/*.yml files when required; but OOTB it should mostly just work?
[11:35:07]  <+jstrachan>    we could try add a migrate goal to the f-m-p 2.x plugin?
[11:35:19]  <+jstrachan>    to basically generate files in src/main/fabric8 that the new f-m-p would use?
[11:35:38]  <+jstrachan>    we could generate the yaml with the new f-m-p and compare too; to see what we broke
[11:35:43]  <ro14nd>    +jstrachan: good idea, like it !
[11:35:52]  <ro14nd>    for the manual I also planned a chapter 
[11:35:59]  <ro14nd>    "Migration from v2 "
[11:37:31]  <+jstrachan>    all the stuff in fabric8-console / devops / ipaas are mostly all custom configurations anyways (rather than generated from spring boot / karaf etc) so just switching to a number of yaml files in src/main/fabric8 would be pretty simple really
[11:37:45]  <+jstrachan>    ah just thought - we've not been considering templates up to now in f-m-p ;)
[11:37:59]  <+jstrachan>    we'd probably wanna replace template params -> configmaps really anwyays
[11:38:00]  <ro14nd>    in devops we have still 31 project using v2, and 13 using v3
[11:39:39]  <+jstrachan>    yeah
[11:40:12]  <+jstrachan>    and most of those we could replace really with just yaml files in the src/main/fabric8 directories - ideally using ${project.version} / ${project.groupId} / ${project.artifactId} expressions
[11:46:29]  salaboy (~salaboy@redhat/jboss/salaboy) left IRC (Ping timeout: 244 seconds)
[11:48:51]  wtrocki ([email protected]) left IRC (Quit: Bye Bye ^^)
[11:50:02]  <ro14nd>    ok, just checked the devops packages: We have three packages "logging", "management" and "metrics" which uses the v3 with the dependency enricher, the other four use v2 (and need the json-packaging 'hack' from #167)

[davsclaus]

Is this still the case?