Apache
/
maven
mirror of https://github.com/apache/maven.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

this has been converted to plugin-overview.apt and developers/plugin-development-guide.apt in maven-site/src/site/apt 

git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209623 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
John Dennis Casey 2005-07-07 17:45:16 +00:00
parent b39c286733
commit 19861bb4b7
1 changed files with 0 additions and 149 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

149
maven-site/src/site/xdoc/developers/plugin-overview.xml
View File

@ -1,149 +0,0 @@
<?xml version="1.0"?>
<!--
/*
* Copyright 2001-2004 The Apache Software Foundation.
*
* Licensed 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.
*/
-->
<document>
<properties>
<title>Maven 2.0 Plugin Development</title>
<author email="jdcasey@apache.org">John Casey</author>
</properties>
<body>
<section name="Introduction">
<subsection name="Similarities to Maven 1.x">
<p> Maven 2.0 is similar to its predecessor in that it has two main
functions. First, it organizes project data into a coherent whole,
and exposes this data for use within the build process. Second, Maven
marshals a set of plugins to do the heavy lifting and execute the
actual steps of the build. </p>
<p> Many things in Maven 2 will have at least superficial familiarity
to users of Maven 1, and the plugin system is no exception. Maven 2
plugins appear to behave much as their 1.x counterparts do. Like 1.x
plugins, they use both project information and custom-defined
configurations to perform their work. Also, Maven 2 plugins are
organized and executed in a coherent way by the build engine itself -
that is to say, the engine is still responsible for organizing and
fulfilling a plugin's requirements before executing the plugin
itself. </p>
<p>Operationally, Maven 2.0 should feel very much like a more
performant big brother of Maven 1.x. While the POM has definitely
changed, it has the same basic layout and features (with notable
additions). However, this is where the similarity ends. Maven 2.0 is
a complete redesign and reimplementation of the Maven build concept.
As such, it has a much different - and more evolved, at least to
our minds ;-) - architecture.</p>
</subsection>
<subsection name="Differences from Maven 1.x">
<p> However similar the architectures may seem, Maven 2 offers a much
richer environment for its plugins than Maven 1 ever did. The new
architecture offers a managed lifecycle, multiple implementation
languages, reusability outside of the build system, and many more
advantages. Arguably the biggest advantage is the ability to write
Maven plugins entirely in Java, which allows developers to tap into a
rich landscape of development and testing tools to aid in their
efforts. </p>
<p> Prior to Maven 2.0, the build system organized relevant plugins
into a loosely defined lifecycle, which was determined based on goal
prerequisites and decoration via preGoals and postGoals. That
experience was critical for the Maven community. It taught us that
even though there may be a million different build scenarios out
there, most of the activities in those builds fit into just a few
broad categories. Moreover, the category to which a goal fits serves
as an accurate predictor for where in the build process the goal
should execute. Drawing on this experience, Maven 2.0 defines a
lifecycle within which plugins are managed according to their
relative position within this lifecycle </p>
<p> Starting with Maven 2.0, plugins implemented in different
programming or scripting languages can coexist within the same build
process. This removes the requirement that plugin developers learn a
particular scripting language in order to interact with Maven. It
also reduced the risk associated with the stability or richness of
any particular scripting language. </p>
<p>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. 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 <i>apply-to-all-these</i> function, and the multiproject plugin
was later added to provide Reactor settings for some common build
types. However, this solution (it <i>is</i> really only one solution,
plus some macros) really never integrated the idea of the
multi-project build process into the maven core conceptual
framework. </p>
</subsection>
<subsection name="Why Change the Plugin Architecture?">
</subsection>
</section>
<section name="Definitions">
<subsection name="What is a Plugin?">
Maven is a framework for the execution of plugin goals. Every action you
take in Maven is really just calling out to an existing maven plugin.
When you compile, clean, create a JAR, generate a site, or execute
unit tests, Maven is executing goals from the appropriate plugins.
</subsection>
<subsection name="What is a Mojo (And Why the H--- is it Named 'Mojo')?">
MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for
"Plain". A Mojo is really just a goal in Maven 2, and plug-ins consist of
any number of goals (Mojos).
</subsection>
<subsection name="What is the Build Lifecycle?">
</subsection>
</section>
<section name="Building a Plugin (in Java)">
<subsection name="Write the Mojo">
</subsection>
<subsection name="Annotate the Mojo">
</subsection>
<subsection name="Build the Plugin (Including POM Modifications)">
</subsection>
</section>
<section name="Plugins in the Build">
<subsection name="I Want My preReqs!">
</subsection>
<subsection name="Decorating Existing Builds (What About pre/postGoals?)">
</subsection>
<subsection
name="Getting Information into the Plugin (Plugin Configuration)">
</subsection>
</section>
<section name="Plugins in the Wild">
<subsection name="Why Might a Plugin Be Maven-Centric?">
</subsection>
<subsection name="Curing Dependence on Maven">
</subsection>
<subsection name="Injecting Configuration into a Plugin">
</subsection>
</section>
<section name="Resources">
<ul>
<li>
<a href="developing-plugins-with-marmalade.html">Developing Plugins with Marmalade</a>
</li>
<li>
<a href="mojo-api-specification.html">MOJO API Specification</a>
</li>
</ul>
</section>
</body>
</document>