Message-ID: <587409829.299755.1369012824951.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_299754_1799720032.1369012824950" ------=_Part_299754_1799720032.1369012824950 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>
It's a fairly common practice to have multiple different "kinds&q= uot; of subprojects in a multimodule build. For instance, multiple presenta= tion-tier webapp modules, several supporting data-layer projects, and in so= me cases even a set of service-layer projects that are architecturally in b= etween the other two.
In most cases, the overall application will be using the same technolo= gies across the board for persistence, web presentation, remoting, etc. wit= h a few special-case "extra" dependencies in any given subproject= . This high level of overlap suggests that these projects should take an ex= tra effort to centralize the specification of shared dependencies. Simple i= nheritance may not be a good option in some cases, because subprojects may = be of a few distinct "flavors", each of which requiring a differe= nt set of dependencies.
My real question here is: Is there ever a case where properly layered = levels of inheritance cannot make this type of application easy to manage?<= /p>
The other templating issue is for sets of plugins and plugin-configura= tions. The argument here is that the project is relying on its parent-POM t= o supply dependencies, or to describe the project itself in other ways. Inj= ecting plugin configuration-sets into this mix can get confusing, because w= hile all subprojects may need to inherit the dependencies, etc. NOT all of = the subprojects will need the same suite of plugins. In other words, the in= heritance of the how of the build should be orthogonal to = the inheritance of what information.
One suggested solution is to have templates of plugins and plugin-conf= igurations which could be referenced by a project in order for it to "= adopt" a certain build behavior. Plugin templates could be specified i= n ancestor POMs, but the suggestion was to keep these templates separate, a= nd have them imported in a similar manner to build extensions. When approac= hed this way, such a template would look quite a bit like a custom lifecycl= e mapping.
My question here: Is there ever a place where the plugin inheritance a= nd custom lifecycle mapping features cannot elegantly handle the scenario? = Perhaps we should look at making the lifecycle mapping mechanism a little m= ore accessible, and promote it as a way of accomplishing this sort of "= ;templating" need?------=_Part_299754_1799720032.1369012824950--