[forge-dev] MavenPluginFacet enhancement: smart plugin resolution

Hello all, I recently contributed to the forge project (FORGE-842) by adding the pluginManagement support to the mavenPluginFacet. One question is still opened, which is the purpose of this post. Basically, it is about a smart plugin resolution, ie having the plugin properties (artifactId, groupId, version,...) automatically resolved when a plugin is defined in a "pluginManagement" section and used in a "plugins" section. Let's take the following example: <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> </plugins> </pluginManagement> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> </plugin> </plugins></build> Currently, a call to the mavenPluginFacet.getPlugin(DependencyBuilder.create("org.apache.maven.plugins:maven-compiler-plugin")).getVersion() will return a null value, because the version is not declared in the "//build/plugins/plugin" section. Maven will, however, resolve the plugin by using the version and configuration of the maven-compiler-plugin declared in the "//build/pluginManagement/plugins" section. Moreover, we should also note that the pluginManagement section will be, most of the time, declared in the parent pom, which makes the smart resolution as follow: 1. Compute the effective pom 2. Resolve the plugin properties My question is: based on the fact that similar implementation was done with Dependency and DependencyManagement sections (in the MavenDependencyFacet and DependencyInstaller), which methods should be implemented ? Following the same logic, we could also thing of a smart "addPlugin" method: what if I add a plugin that is already managed, with the same version of the managed plugin ? With some configuration element(s) being the same as the managed plugin ? ... Based on your answers, I will create a FORGE issue and will try to implement the missing methods. Thanks, Charles.