Message-ID: <1533385724.26953.1417117831339.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_26952_609697023.1417117831339" ------=_Part_26952_609697023.1417117831339 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
There have been a few requests to make management of dependency and plu= gin sets easier. I wanted to start this page to capture these use cases, an= d see if we can include some of these concepts in the next major release.= p>=20
It's a fairly common practice to have multiple different "kinds&qu= ot; of subprojects in a multimodule build. For instance, multiple presentat= ion-tier webapp modules, several supporting data-layer projects, and in som= e cases even a set of service-layer projects that are architecturally in be= tween the other two.=20
In most cases, the overall application will be using the same technolog= ies across the board for persistence, web presentation, remoting, etc. with= a few special-case "extra" dependencies in any given subproject.= This high level of overlap suggests that these projects should take an ext= ra effort to centralize the specification of shared dependencies. Simple in= heritance may not be a good option in some cases, because subprojects may b= e of a few distinct "flavors", each of which requiring a differen= t set of dependencies.=20
My real question here is: Is there ever a case where properly layered l= evels of inheritance cannot make this type of application easy to manage?= p>=20=20
The other templating issue is for sets of plugins and plugin-configurat= ions. The argument here is that the project is relying on its parent-POM to= supply dependencies, or to describe the project itself in other ways. Inje= cting plugin configuration-sets into this mix can get confusing, because wh= ile all subprojects may need to inherit the dependencies, etc. NOT all of t= he subprojects will need the same suite of plugins. In other words, the inh= eritance of the how of the build should be orthogonal to t= he inheritance of what information.=20
One suggested solution is to have templates of plugins and plugin-confi= gurations which could be referenced by a project in order for it to "a= dopt" a certain build behavior. Plugin templates could be specified in= ancestor POMs, but the suggestion was to keep these templates separate, an= d have them imported in a similar manner to build extensions. When approach= ed this way, such a template would look quite a bit like a custom lifecycle= mapping.=20
My question here: Is there ever a place where the plugin inheritance an= d custom lifecycle mapping features cannot elegantly handle the scenario? P= erhaps we should look at making the lifecycle mapping mechanism a little mo= re accessible, and promote it as a way of accomplishing this sort of "= templating" need?