fabric8-maven-plugin: Unable to build multi-module project with fmp 3.5.34

I agree: breaking changes should be reserved to major versions and shouldn’t occur on micro versions (as is the case here).

Le 26 févr. 2018 à 07:39, Georgios Andrianakis notifications@github.com a écrit :

Hello @piyush1594,

That’s up to you 😃. I personally think that the default behavior should be reverted to what it was in FMP 3.5.33, but that’s just my opinion.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Let me just briefly explain the motivation for the original change which was not meant to break backwards compatibility.

For projects of type pom by default fabric8-maven-plugin is always skipped. However, there are very valid uses cases which define a fabric8-maven-plugin configuration for only building images (without compiling). In order to not skip such projects the default behaviour was changed, that the fmp run is skipped in pom typed projects only when no fmp build configuration is attached. The rationale is that, if you configure the plugin, then you expect it to run (or the other way round, people were suprised that it has been not run although a plugin has been configured). Having the plugin be skipped by default is very confusing and caused several hours of debugging.

So, it should be backwards compatible if your pom does not contain a build configuration in the fmp plugin configuration. If used as default for multi module children, the configuration should go in a <pluginManagement> section anyway (and not in a <plugin> configuration directly), so that the build is skipped like before.

Actually, I’m happy to revert this behaviour, if we add it to a minor release change (e.g. for 3.6) as it is really counter intuitive, if you configure a f-m-p build in a pom typed project (e.g. when this project is only used for building, nothing else) and then the build doesn’t work because ‘skip’ is the default.

But maybe it would also work for you, too, to move the default fmp build configuration in a parent pom.xml from a <plugin> to a <pluginManagement> section ? (which I would do anyway).

Let me know, how you would like to proceed …

I understand there are valid use cases for that change but shouldn’t these use cases be the one that need to change as opposed to breaking things that were working with previous minor releases? In any case, I’d be in favor of reverting that change and deferring it to a minor release (at the very least). That new behavior should be also documented (probably by explaining as you just did).

Regarding the pluginManagement vs. plugin issue: it is doable. We already have a parent where the plugin is configured. We used plugin as opposed to pluginManagement because the plugin is used in exactly the same way in all children projects and so we wanted to avoid repeating the plugin declaration in all projects if there was no need to do so. Also, our parent is actually a child of another parent which does declare the plugin in a pluginManagement section.

Finally, personally, I find it weird to use Maven to declare a project as a pom just to build an external resource that has not much to do with a java artifact. Pom projects should be reserved to BOMs and parent definition, in my opinion, but I’m no Maven expert. So, supporting these use cases should be secondary to supporting projects which actually build java applications. But that’s only my personal opinion 😃

A breaking change in default behavior in a minor release is definitely not expected. Breaking changes should be reserved to major versions. @geoand we could mitigate the issue by adding the flag to our parent POM… if that’s really the issue.