where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue.
 - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`.
       Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
 - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.

+ Make sure you have a [GitHub account](https://github.com/signup/free).
+ If you're planning to implement a new feature, it makes sense to discuss your changes
  on the [dev list](https://maven.apache.org/mailing-lists.html) first.
  This way you can make sure you're not wasting your time on something that isn't
  considered to be in Apache Maven's scope.
+ Submit a ticket for your issue, assuming one does not already exist.

    echo "The java(1) command does not exist in PATH nor is JAVA_HOME set, so Apache Maven cannot be started." >&2
    exit 1
  fi
fi

# traverses directory structure from process work directory to filesystem root
# first directory with .mvn subdirectory is considered project base directory
find_maven_basedir() {
(
  basedir=`find_file_argument_basedir "$@"`
  wdir="$basedir"
  while [ "$wdir" != '/' ] ; do
    if [ -d "$wdir"/.mvn ] ; then

-----------------------------------
You can download the release source from our [download page][maven-download].

Contributing
------------

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
-------

    portions thereof.

    1.4. "Executable" means the Covered Software in any form other than
    Source Code.

    1.5. "Initial Developer" means the individual or entity that first
    makes Original Software available under this License.

    1.6. "Larger Work" means a work which combines Covered Software or
    portions thereof with code not governed by the terms of this License.

~~ under the License.

  ---
  Getting to Plexus-configured Mojos
  ---
  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

     1. plugin goal execution in a child is usually simply appended (at end): you can't try to insert in the middle of pre-existing inherited executions,

     2. append happens at plugin level first, then goal level, independently from phases.
        This means for example that adding pluginA:goal2 to pre-existing (pluginA:goal1, pluginB:goal) will lead to (pluginA:goal1, pluginA:goal2, pluginB:goal)

        <goals>
          <goal>process</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  .
  .
  .
</plugins>

 JAR plugin as well as its dependencies. The realms noted above are setup
 in a hierarchical structure where the resources in the parent realms are
 available but the <<realm is searched first before a search is made in
 the parent realm>>.

 Plugins are guaranteed to be provided the resources found in
 <<<plexus.core>>> and <<<plexus.core.maven>>> realms at run-time if required.

URLClassLoader. Mercury would be responsible for resolving and retrieving the dependencies which would then be used to populate a ClassRealm where there would be a connection to the host applications ClassRealm as the parent but the search order would be child first, and the parent ClassRealm can optionally choose to limit the searching to particular classes. The application ClassRealm, or parent ClassRealm, should only expose the API in the form of and application interface and model classes that may be required...