Background: Lifecycle mappings are instructions for the Maven integration in the Eclipse IDE (M2E) what to do with Maven plugins; see e.g. https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html for an introduction.
yang-maven-plugin currently has no built-in lifecycle mapping. The current solution thus is to either:
(a) manually yourself set an <ignore /> for yang-maven-plugin, which will cause M2E to completely ignore yang-maven-plugin, and so end-users just do "mvn generate-sources" whenever they initially import projects, change *.yang models, or switch branches (and the branch switching IMHO is in practice the most common and often used use case requiring manual action among the three...).
(b) use the M2Eclipse extension for the yang-maven-plugin which is available in the org.opendaylight.yangide.m2e.yang Eclipse plugin that is part of yangide (YangProjectConfigurator).
I used to myself use, and through https://github.com/vorburger/opendaylight-eclipse-setup advocate for, the option (b) for the last 6 months. But I've meanwhile changed my mind and am about to switch this to (a) instead, because yangide:
seems to have a non-negligible impact on Eclipse workspace build performance due to its "YANG Indexing";
(ii) embeds a easily outdated copy of yangtools JARs in its org.opendaylight.yangide.core Eclipse Plugin's libs/;
(iii) is not currently actively maintained.
Long story short, and to get to the point of this enhancement: In an ideal world, from what I understand about this stuff, yang-maven-plugin would itself already provide lifecycle mapping metadata - https://wiki.eclipse.org/M2E_compatible_maven_plugins describes how this can be achieved. This would apparently also require the yang-maven-plugin to be written to be "IDE-invokeable" by using, only BuildContext to write files and emit validation errors.
It doesn't look very complicated; but the one thing that I would be slightly worried about is performance; if m2e assume stateless yang-maven-plugin with no static (I'm not sure it does; to be explored), it may be slow if it has to re-construct its "index" constantly? (That's basically what the index that part of yangide is for, which takes time o construct, from what I understand.)
I personally don't have bandwidth to dig further into this in the short term, but I'll keep it on a list of possible things to look at over the next.. months, likely. If anyone reads this and would like to have a stab at it, please go for it and don't let me hold you back. (But I'd certainly be willing to collaborate with/review/test etc. any work related to this.)