From b8042e780df322a319d8cca40ddc985701c8034f Mon Sep 17 00:00:00 2001 From: John Dennis Casey Date: Wed, 25 May 2005 22:51:13 +0000 Subject: [PATCH] git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@178545 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/site/xdoc/developers/plugin-overview.xml | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/maven-site/src/site/xdoc/developers/plugin-overview.xml b/maven-site/src/site/xdoc/developers/plugin-overview.xml index 3e82ce3adf..59892e87af 100644 --- a/maven-site/src/site/xdoc/developers/plugin-overview.xml +++ b/maven-site/src/site/xdoc/developers/plugin-overview.xml @@ -78,9 +78,19 @@

Also starting with Maven 2.0 is an effort to integrate multiproject builds directly into the core architecture. In Maven 1.x, many large projects were fragmented into smaller builds to sidestep issues such - as conditional compilation of a subset of classes; separation - of client-server code; or cyclical dependencies between - distinct application libraries.

+ as conditional compilation of a subset of classes; separation of + client-server code; or cyclical dependencies between distinct + application libraries. This in turn created extra complexity with + running builds, since multiple builds had to be run in order to build + the application as a whole - one or more per project. While the first + version (1.x) did indeed address this new multiple projects issue, it + did so as an afterthought. The Reactor was created to act as a sort + of apply-to-all-these function, and the multiproject plugin + was later added to provide Reactor settings for some common build + types. However, this solution (it is really only one solution, + plus some macros) really never integrated the idea of the + multi-project build process into the maven core conceptual + framework.