1 files changed, 139 insertions, 0 deletions
diff --git a/framework/src/maven/apache-maven-3.3.3/maven-core/src/site/apt/configuration-management.apt b/framework/src/maven/apache-maven-3.3.3/maven-core/src/site/apt/configuration-management.apt
new file mode 100644
index 00000000..4af0f0b1
--- /dev/null
+++ b/framework/src/maven/apache-maven-3.3.3/maven-core/src/site/apt/configuration-management.apt
@@ -0,0 +1,139 @@
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements.  See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership.  The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License.  You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied.  See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+ -----
+ Maven configuration management
+ -----
+ The Maven Team
+ -----
+
+Configuration levels in maven
+
+ In maven configuration control happens on four differ levels: the site level, the group level,
+ the project level, and the user level. On the site level you can configure maven for all users
+ utilizing the local installation, the group level allows configuration management for all the projects
+ that belong to the same group, the project level allows configuration management at
+ the project level, and the user level allows users to override settings on
+ the site level, group level and project level.
+
+* Site configuration
+
+ At the site level all configuration is achieved by tweaking the the various files that
+ are available in the ${maven.home}/site-configuration directory
+
++-----+
+${maven.home}
+     |
+     +--- maven.properties
++-----+
+
+* Group configuration
+
+ As far as properties go for an entire build the maven.properties could be placed at
+ the top of the group but I'm not really sure how this might work. There could probably
+ also be a directory for plugins.xml and maven.properties.
+
+* Project configuration
+
+ At the project level all configuration is achieved by tweaking the POM. One of the differences between
+ maven 1.x and 2.x is that all project parameterization occurs in the POM and not from properties
+ files.
+
+ For many of the more advanced features in Maven2 it is critical that POMs be available in the local repository.
+ Features like transitive dependencies and the new parent specification mechanism. The problem we run into is
+ that currently we have information about a project scattered across the project.xml and the
+ various properties files. What needs to be done is to encapsulate all of this in the POM.
+
+ Typically users parameterize the use of plugins, or have custom values like ${user.name}
+ for use in elements like the <developerConnection/>. It would be idea if we
+ could encapsulate everything we need about the project in the POM including
+ plugin parameters and anything else.
+
+ We once had a document that Vincent and I agreed upon and I was about to
+ implement it and then I disappeared for 8 months so it never came to pass.
+
+ So I guess it's important to figure out what people are using propeties
+ files for and see if we can't incorporate it all into the POM. Or if we do
+ have properties file (something I would like to avoid) say they don't
+ contribute in any meaningful way to information in the POM. For example a
+ properties file could be used the specify $ so it can be interpolated in
+ <developerConnection/> but you couldn't use a properties file to specify the
+ version of your project say. Anyway, food for thought to begin with.
+
+ - elements that are critical for pom dissemination
+ - those that are used locally by the user like <developerConnection/>
+
+* User configuration
+
+ User configuration which is utilized site wide are controlled with the ${user.home}/.m2/maven.properties.
+
+ User configuration which is utilized at the project level are controlled with the
+ ${project.home}/maven.properties file.
+
+Plugin configuration
+
+ The configuration of plugins is of the same form as the maven {{{plugin-descriptors}plugin descriptors}}
+ themselves:
+
++-----+
+<plugins>
+  <plugin>
+   <id>xdoc</id>
+   <version>1.0</version>
+   <parameters>
+     <parameter>
+       <name>theme</name>
+       <value>classic</value>
+     </parameter>
+   </parameters>
+  </plugin>
+</plugins>
++-----+
+
+Unified source directory
+
+ Unified source directory structure that is analagous to the repository
+ itself. This way locations of intermediary artifacts of a build would be
+ in a known location. This would also help with developer setup i.e. getting
+ new developers up and running. They could run a maven command and have all
+ their source trees set up in the same way as their collegues.
+
+ here's what I do currently in the netbeans part of the mevenide project to
+ find the relevant subprojects/sibling projects. I check if the user has
+ defined the maven.multiproject.includes property in any of his properties
+ files for the current project. if yes. then I'm able to find projects that
+ can be offered to be opened together with the current project.
+ problems with the current solution are:
+ 1. information is duplicate. once in POM's dependencies and once in the
+ maven.multiproject.includes property.
+ 2. it works without problems only for projects with relative paths, eg. from
+ one CVS repository.. for projects from multiple SCM repositories it's harder
+ to maintain the same relative links on all developer computers.
+ not sure the unified source directory structure addresses this issue.
+
+ Properties
+
+ maven.user.config.dir (system,default=${user.home}/.m2)
+ maven.home            (system,user,default=${user.home}/m2)
+ maven.repo.local      (system,user,default=${maven.user.config.dir}/repository)
+
+ We need to define what happens in the when things are not setup correctly
+
+ o ~/.m2 directory does not exist
+ o ~/.m2/maven.properties does not exist
+ o if they once existed but now to do not exist
+ o what the installer will take care of of what we can recover from