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]
