Heh, when I first read it, I thought you took the proposal and made a jira until I saw the date ;-) Freaky.
-----Original Message----- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 12:12 AM To: Maven Developers List Subject: Re: [proposal] "Make like" reactor build mode Hi, FYI I reported this as a Jira issue almost a year ago: http://jira.codehaus.org/browse/MNG-2576 oh. I just saw your comment on the issue referring to this. Yes, this is exactly the same issue ;) -- Kenney Brian E. Fox wrote: > http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode > > > > "Make" like build behavior mode > > 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 bottom up. Often times a build, especially large ones, will contain > many modules 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 > packages: > > > +---packages > > | +---a-package > > | +---b-package > > | \---c-package > > +---services > > | +---a-service > > | +---b-service > > | \---c-service > > \---ui > > +---a-ui > > +---b-ui > > \---c-ui > > The packages inherit from the package parent, etc. Assume that > "A-package" depends on "a-service" "b-service" and "a-ui" > > In Maven, there is currently no easy way to make a change to "a-service" > 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. > > Out of Scope > > 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 > actually changed) This is simply intended to be an extension to the > reactor behavior in choosing which projects should be included in the > reactor. > > Proposed Solution > > 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 install" (-A for > all) > > 3. Maven walks up the parent tree to see how far up the source goes. > Then any dependencies in the graph that are found in the contained > source on disk are ordered and built. Everything else is ignored in the > build. > > Alternate Use Case: > > 2. Instead of going to "a-package" and executing mvn, the developer > goes to the top level parent and executes "mvn -Aa-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 included in the subtree. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
