The super model is where we place all the values which we believe to be standard, values that can be shared and
 utilized across all your Maven projects.

+-----+
 m0 <- m1 <- m2
+-----+

 which is transformed into

+-----+
 super model <- m0 <- m1 <- m2
+-----+

+-----+
<project>
 <modelVersion>4.0.0</modelVersion>
 <parent>
   <groupId></groupId>
   <artifactId></artifactId>
   <version></version>

If you are interested in the development of Maven, please consult the
documentation first and afterward you are welcome to join the developers
mailing list to ask questions or discuss new ideas/features/bugs etc.

Take a look into the [contribution guidelines](CONTRIBUTING.md).

License
-------
This code is under the [Apache License, Version 2.0, January 2004][license].

See the [`NOTICE`](./NOTICE) file for required notices and attributions.

Contributing to Apache Maven
======================

You have found a bug or you have an idea for a cool new feature? Contributing
code is a great way to give something back to the open source community. Before
you dig right into the code, there are a few guidelines that we need
contributors to follow so that we can have a chance of keeping on top of
things.

Some of the ideas are documented in the [Maven Wiki][maven-wiki]

    license or settlement) prior to the initiation of patent
    infringement litigation, then the reasonable value of the licenses
    granted by such Participant under Sections 2.1 or 2.2 shall be taken
    into account in determining the amount or value of any payment or
    license.

    6.4. In the event of termination under Sections 6.1 or 6.2 above,
    all end user licenses that have been validly granted by You or any

  should result in similar modification. This object is not meant to be
  static within the build process, but rather to be setup as an aggregation of
  all settings-related information passed into the system.

** Control over downloads

  Find the control point for m2 using maven-wagon. At this point, inject
  a offline status parameter which is used when retrieving the specific Wagon.

 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.

  ---
  John Casey
  ---
  2005-04-29

Abstract

  We're moving toward integrating mojos as first-class plexus components, while
  at the same time avoiding introducing required plexus dependencies into the
  mojo development model.

  In order to really achieve this, we need mojo configurations (which are
  provided both in terms of static expressions that are just looked up, and

 with its <<<DefaultExceptionHandler>>> implementation
 ({{{./xref/org/apache/maven/exception/DefaultExceptionHandler.html}source}}), use to transform exception into useful end-user messages.

* Toolchains

 * {{{./toolchains.html}Toolchains descriptor reference}},

        <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
      </phases>
    </lifecycle>
  </lifecycles>
</configuration>

We need to turn this list of phases into a set of plugin objects that have an XML representation like the following:

<plugins>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <executions>

 *
 * For a particular application plugin there will be a declarative descriptor for that plugin type.
 *
 * - nexus - the plugin class - UI to contribute - what JS to hook into the UI - what resources to
 * load into the UI - having packed or unpacked plugins, and positioning resources if necessary -
 * maven can work out of the classloader, nexus plugins probably couldn't give the js and image
 * resources
 *