On Sep 4, 2007, at 6:10 PM, 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.
+---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.
I'm confused... can't you just:
(cd services/a-service; mvn install)
Or perhaps even:
mvn -f services/a-service/pom.xml install
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.
Ohhh... I see, you want the build of "a-service" to also build its
dependencies if they are local? That would be rather handy ;-) Even
handier if mvn plugins were a wee smarter about skipping things when
they don't need to be done too, but thats another problem...
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.
Hey, I'm not sure how much this would help other folks... but
sometimes that graph building stuff that gets done before the reactor
gets kicked off takes a long time. For huge projects like Apache
Geronimo (gosh, 200+ modules now) it does take a while to get things
started. Would there be any value in caching a serialized version of
the object graph and using that unless a pom.xml has changed which
would invalidate it? perhaps toss the cached pom into each
modules .m2/pom.ser or something?
I dunno... might only hurt folks with massive projects that really
should refactor into smaller chucks so let them live with the pain
until they learn ;-)
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
