Message-ID: <1914030499.2317.1369293929200.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2316_1606989253.1369293929200" ------=_Part_2316_1606989253.1369293929200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Maven currently has a top down build approach where you start at the top= of a reactor and build all children. One of the most common requests I get= from my developers is an easy way to build certain artifacts from the bott= om up. Often times a build, especially large ones, will contain many module= s needed for a "full" build, but are actually made up of pockets = of interdependencies. It's not always possible to logically group these all= together with a common parent to enable easily building a subtree.
For example, you may have a project comprised of services, ui's and pack=
The packages inherit from the package parent, etc. Assume that "A-p= ackage" depends on "a-service" "b-service" and &qu= ot;a-ui"
In Maven, there is currently no easy way to make a change to "a-ser= vice" and build it and the package at once. This can be controlled to = some extent with modules in profiles, but this quickly becomes unwieldy and= doesn't support the granularity needed.
It is out of scope for this proposal to determine if a project actually = needs to be rebuilt based on the contents. (ie checking if anything has act= ually changed) This is simply intended to be an extension to the reactor be= havior in choosing which projects should be included in the reactor.=C2=A0<= /p>
The ideal use case for this issue is:
1. Developer makes change to code in "a-service"
2. Developer goes to "a-package" and executes "mvn -A ins= tall"=C2=A0 (-A for all)
3. Maven walks up the parent tree to see how far up the source goes. The= n any dependencies in the graph that are found in the contained source on d= isk are ordered and built. Everything else is ignored in the build.
2. Instead of going to=C2=A0 "a-package" and executing mvn, th= e developer goes to the top level parent and executes "mvn -Apackages/= a-package" (in this case defining the module that should be considered= for dependency graphing)
3. Maven builds the graph and builds what is needed.
This use case isn't ideal but is probably easier to implement since the = top level parent doesn't need to be located and everything to be built is i= ncluded in the subtree.=C2=A0
The maven-reactor-plugin can be used = today to build stuff. We'd like to port at least reactor:resume, reactor:m= ake, reactor:makeDependents into core. I'm thinking it would go something = like this:
At least at first, core would not include the new reactor:makeScmChanges= because that would require maven-core to depend on maven-scm.------=_Part_2316_1606989253.1369293929200--