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

move site out of components 

git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330439 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Brett Leslie Porter 2005-11-03 04:21:08 +00:00
parent c566d0e396
commit 58cd5a1d93
137 changed files with 0 additions and 14234 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
maven-site/my-app/pom.xml
View File

@ -1,71 +0,0 @@
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<organization>
<name>MyCompany Inc</name>
</organization>
<properties>
<pkey>pvalue</pkey>
<target>${pom.build.directory}</target>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<filters>
<filter>src/main/filters/filters.properties</filter>
</filters>
<!--
<outputDirectory>${pom.build.directory}</outputDirectory>
-->
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>org.com.foo.App</mainClass>
<packageName>org.com.foo.app</packageName>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${target}</url>
</manifestEntries>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

1
maven-site/my-app/src/main/filters/filters.properties
View File

@ -1 +0,0 @@
name=jason

13
maven-site/my-app/src/main/java/com/mycompany/app/App.java
View File

@ -1,13 +0,0 @@
package com.mycompany.app;
/**
* Hello world!
*
*/
public class App
{
public static void main( String[] args )
{
System.out.println( "Hello World!" );
}
}

6
maven-site/my-app/src/main/resources/META-INF/application.properties
View File

@ -1,6 +0,0 @@
name=${name}
project=${pom.name}
value=${pkey}
java.version=${java.version}
target=${target}
foo=${pom.build.directory}

596
maven-site/my-app/src/site/apt/format.apt
View File

@ -1,596 +0,0 @@
The APT format
~~~~~~~~~~~~~~
In the following section, boxes containing text in typewriter-like font are
examples of APT source.
* Document structure
~~~~~~~~~~~~~~~~~~~~
A short APT document is contained in a single text file. A longer document
may be contained in a ordered list of text files. For instance, first text
file contains section 1, second text file contains section 2, and so on.
[Note:] Splitting the APT document in several text files on a section
boundary is not mandatory. The split may occur anywhere.
However doing so is recommended because a text file containing a
section is by itself a valid APT document.
A file contains a sequence of paragraphs and ``displays'' (non paragraphs
such as tables) separated by open lines.
A paragraph is simply a sequence of consecutive text lines.
+------------------------------------------------------------------------+
First line of first paragraph.
Second line of first paragraph.
Third line of first paragraph.
Line 1 of paragraph 2 (separated from first paragraph by an open line).
Line 2 of paragraph 2.
+------------------------------------------------------------------------+
The indentation of the first line of a paragraph is the main method used by
an APT processor to recognize the type of the paragraph. For example, a
section title must not be indented at all.
A ``plain'' paragraph must be indented by a certain amount of space. For
example, a plain paragraph which is not contained in a list may be indented
by two spaces.
+-------------------------------------------------+
My section title (not indented).
My paragraph first line (indented by 2 spaces).
+-------------------------------------------------+
Indentation is not rigid. Any amount of space will do. You don't even need
to use a consistent indentation all over your document. What really matters
for an APT processor is whether the paragraph is not indented at all or,
when inside a list, whether a paragraph is more or less indented than the
first item of the list (more about this later).
+-------------------------------------------------------+
First paragraph has its first line indented by four
spaces. Then the author did even bother to indent the
other lines of the paragraph.
Second paragraph contains several lines which are all
indented by two spaces. This style is much nicer than
the one used for the previous paragraph.
+-------------------------------------------------------+
Note that tabs are expanded with a tab width set to 8.
* Document elements
~~~~~~~~~~~~~~~~~~~
** Block level elements
~~~~~~~~~~~~~~~~~~~~~~~
*** Title
~~~~~~~~~~
A title is optional. If used, it must appear as the first block of the
document.
+----------------------------------------------------------------------------+
------
Title
------
Author
------
Date
+----------------------------------------------------------------------------+
A title block is indented (centering it is nicer). It begins with a line
containing at least 3 dashes (<<<--->>>).
After the first <<<--->>> line, one or several consecutive lines of text
(implicit line break after each line) specify the title of the document.
This text may immediately be followed by another <<<--->>> line and one or
several consecutive lines of text which specifies the author of the
document.
The author sub-block may optionaly be followed by a date sub-block using the
same syntax.
The following example is used for a document with an title and a date but
with no declared author.
+----------------------------------------------------------------------------+
------
Title
------
------
Date
------
+----------------------------------------------------------------------------+
The last line is ignored. It is just there to make the block nicer.
*** Paragraph
~~~~~~~~~~~~~
Paragraphs other than the title block may appear before the first section.
+----------------------+
Paragraph 1, line 1.
Paragraph 1, line 2.
Paragraph 2, line 1.
Paragraph 2, line 2.
+----------------------+
Paragraphs are indented. They have already been described in the {{document
structure}} section.
*** Section
~~~~~~~~~~~
Sections are created by inserting section titles into the document. Simple
documents need not contain sections.
+-----------------------------------+
Section title
* Sub-section title
** Sub-sub-section title
*** Sub-sub-sub-section title
**** Sub-sub-sub-sub-section title
+-----------------------------------+
Section titles are not indented. A sub-section title begins with one
asterisk (<<<*>>>), a sub-sub-section title begins with two asterisks
(<<<**>>>), and so forth up to four sub-section levels.
*** List
~~~~~~~~
+---------------------------------------+
* List item 1.
* List item 2.
Paragraph contained in list item 2.
* Sub-list item 1.
* Sub-list item 2.
* List item 3.
+---------------------------------------+
List items are indented and begin with a asterisk (<<<*>>>).
Plain paragraphs more indented than the first list item are nested in that
list. Displays such as tables (not indented) are always nested in the
current list.
To nest a list inside a list, indent its first item more than its parent
list. To end a list, add a paragraph or list item less indented than the
current list.
Section titles always end a list. Displays cannot end a list but the
<<<[]>>> pseudo-element may be used to force the end of a list.
+------------------------------------+
* List item 3.
Force end of list:
[]
--------------------------------------------
Verbatim text not contained in list item 3
--------------------------------------------
+------------------------------------+
In the previous example, without the <<<[]>>>, the verbatim text (not
indented as all displays) would have been contained in list item 3.
A single <<<[]>>> may be used to end several nested lists at the same
time. The indentation of <<<[]>>> may be used to specify exactly which
lists should be ended. Example:
+------------------------------------+
* List item 1.
* List item 2.
* Sub-list item 1.
* Sub-list item 2.
[]
-------------------------------------------------------------------
Verbatim text contained in list item 2, but not in sub-list item 2
-------------------------------------------------------------------
+------------------------------------+
There are three kind of lists, the bulleted lists we have already described,
the numbered lists and the definition lists.
+-----------------------------------------+
[[1]] Numbered item 1.
[[A]] Numbered item A.
[[B]] Numbered item B.
[[2]] Numbered item 2.
+-----------------------------------------+
A numbered list item begins with a label beetween two square brackets. The
label of the first item establishes the numbering scheme for the whole list:
[<<<[[1\]\]>>>] Decimal numbering: 1, 2, 3, 4, etc.
[<<<[[a\]\]>>>] Lower-alpha numbering: a, b, c, d, etc.
[<<<[[A\]\]>>>] Upper-alpha numbering: A, B, C, D, etc.
[<<<[[i\]\]>>>] Lower-roman numbering: i, ii, iii, iv, etc.
[<<<[[I\]\]>>>] Upper-roman numbering: I, II, III, IV, etc.
The labels of the items other than the first one are ignored. It is
recommended to take the time to type the correct label for each item in
order to keep the APT source document readable.
+-------------------------------------------+
[Defined term 1] of definition list 2.
[Defined term 2] of definition list 2.
+-------------------------------------------+
A definition list item begins with a defined term: text between square
brackets.
*** Verbatim text
~~~~~~~~~~~~~~~~~
+----------------------------------------+
----------------------------------------
Verbatim
text,
preformatted,
escaped.
----------------------------------------
+----------------------------------------+
A verbatim block is not indented. It begins with a non indented line
containing at least 3 dashes (<<<--->>>). It ends with a similar line.
<<<+-->>> instead of <<<--->>> draws a box around verbatim text.
Like in HTML, verbatim text is preformatted. Unlike HTML, verbatim text is
escaped: inside a verbatim display, markup is not interpreted by the APT
processor.
*** Figure
~~~~~~~~~~
+---------------------------+
[Figure name] Figure caption
+---------------------------+
A figure block is not indented. It begins with the figure name between
square brackets. The figure name is optionally followed by some text: the
figure caption.
The figure name is the pathname of the file containing the figure but
without an extension. Example: if your figure is contained in
<<</home/joe/docs/mylogo.jpeg>>>, the figure name is
<<</home/joe/docs/mylogo>>>.
If the figure name comes from a relative pathname (recommended practice)
rather than from an absolute pathname, this relative pathname is taken to be
relative to the directory of the current APT document (a la HTML)
rather than relative to the current working directory.
Why not leave the file extension in the figure name? This is better
explained by an example. You need to convert an APT document to PostScript
and your figure name is <<</home/joe/docs/mylogo>>>. A APT processor will
first try to load <<</home/joe/docs/mylogo.eps>>>. When the desired format
is not found, a APT processor tries to convert one of the existing
formats. In our example, the APT processor tries to convert
<<</home/joe/docs/mylogo.jpeg>>> to encapsulated PostScript.
*** Table
~~~~~~~~~
A table block is not indented. It begins with a non indented line containing
an asterisk and at least 2 dashes (<<<*-->>>). It ends with a
similar line.
The first line is not only used to recognize a table but also to specify
column justification. In the following example,
* the second asterisk (<<<*>>>) is used to specify that column 1 is
centered,
* the plus sign (<<<+>>>) specifies that column 2 is left aligned,
* the colon (<<<:>>>) specifies that column 3 is right aligned.
[]
+---------------------------------------------+
*----------*--------------+----------------:
| Centered | Left-aligned | Right-aligned |
| cell 1,1 | cell 1,2 | cell 1,3 |
*----------*--------------+----------------:
| cell 2,1 | cell 2,2 | cell 2,3 |
*----------*--------------+----------------:
Table caption
+---------------------------------------------+
Rows are separated by a non indented line beginning with <<<*-->>>.
An optional table caption (non indented text) may immediately follow the
table.
Rows may contain single line or multiple line cells. Each line of cell text
is separated from the adjacent cell by the pipe character (<<<|>>>).
(<<<|>>> may be used in the cell text if quoted: <<<\\|>>>.)
The last <<<|>>> is only used to make the table nicer. The first <<<|>>> is
not only used to make the table nicer, but also to specify that a grid is to
be drawn around table cells.
The following example shows a simple table with no grid and no caption.
+---------------+
*-----*------*
cell | cell
*-----*------*
cell | cell
*-----*------*
+---------------+
*** Horizontal rule
~~~~~~~~~~~~~~~~~~~
+---------------------+
=====================
+---------------------+
A non indented line containing at least 3 equal signs (<<<===>>>).
*** Page break
~~~~~~~~~~~~~~
+---+
^L
+---+
A non indented line containing a single form feed character (Control-L).
** Text level elements
~~~~~~~~~~~~~~~~~~~~~~
*** Font
~~~~~~~~
+-----------------------------------------------------+
<Italic> font. <<Bold>> font. <<<Monospaced>>> font.
+-----------------------------------------------------+
Text between \< and > must be rendered in italic. Text between \<\< and >>
must be rendered in bold. Text between \<\<\< and >>> must be rendered using
a monospaced, typewriter-like font.
Font elements may appear anywhere except inside other font elements.
It is not recommended to use font elements inside titles, section titles,
links and defined terms because a APT processor automatically applies
appropriate font styles to these elements.
*** Anchor and link
~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------+
{Anchor}. Link to {{anchor}}. Link to {{http://www.pixware.fr}}.
Link to {{{anchor}showing alternate text}}.
Link to {{{http://www.pixware.fr}Pixware home page}}.
+-----------------------------------------------------------------+
Text between curly braces (<<<\{}>>>) specifies an anchor. Text between
double curly braces (<<<\{\{}}>>>) specifies a link.
It is an error to create a link element that does not refer to an anchor of
the same name. The name of an anchor/link is its text with all non
alphanumeric characters stripped.
This rule does not apply to links to <external> anchors. Text beginning
with <<<http:/>>>, <<<https:/>>>, <<<ftp:/>>>, <<<file:/>>>, <<<mailto:>>>,
<<<../>>>, <<<./>>> (<<<..\\>>> and <<<.\\>>> on Windows) is recognized as
an external anchor name.
When the construct <<\{\{\{>><name><<}>><text><<}}>> is used, the link text
<text> may differ from the link name <name>.
Anchor/link elements may appear anywhere except inside other anchor/link
elements.
Section titles are implicitly defined anchors.
*** Line break
~~~~~~~~~~~~~~
+-------------+
Force line\
break.
+-------------+
A backslash character (<<<\\>>>) followed by a newline character.
Line breaks must not be used inside titles and tables (which are line
oriented blocks with implicit line breaks).
*** Non breaking space
~~~~~~~~~~~~~~~~~~~~~~
+----------------------+
Non\ breaking\ space.
+----------------------+
A backslash character (<<<\\>>>) followed by a space character.
*** Special character
~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------+
Escaped special characters: \~, \=, \-, \+, \*, \[, \], \<, \>, \{, \}, \\.
+---------------------------------------------------------------------------+
In certain contexts, these characters have a special meaning and therefore
must be escaped if needed as is. They are escaped by adding a backslash in
front of them. The backslash may itself be escaped by adding another
backslash in front of it.
Note that an asterisk, for example, needs to be escaped only if its begins a
paragraph. (<<<*>>> has no special meaning in the middle of a paragraph.)
+--------------------------------------+
Copyright symbol: \251, \xA9, \u00a9.
+--------------------------------------+
Latin-1 characters (whatever is the encoding of the APT document) may be
specified by their codes using a backslash followed by one to three octal
digits or by using the <<<\x>>><NN> notation, where <NN> are two hexadecimal
digits.
Unicode characters may be specified by their codes using the <<<\u>>><NNNN>
notation, where <NNNN> are four hexadecimal digits.
*** Comment
~~~~~~~~~~~
+---------------+
~~Commented out.
+---------------+
Text found after two tildes (<<<\~~>>>) is ignored up to the end of line.
A line of <<<~>>> is often used to ``underline'' section titles in order to
make them stand out of other paragraphs.
* The APT format at a glance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------------------------------------------------------
------
Title
------
Author
------
Date
Paragraph 1, line 1.
Paragraph 1, line 2.
Paragraph 2, line 1.
Paragraph 2, line 2.
Section title
* Sub-section title
** Sub-sub-section title
*** Sub-sub-sub-section title
**** Sub-sub-sub-sub-section title
* List item 1.
* List item 2.
Paragraph contained in list item 2.
* Sub-list item 1.
* Sub-list item 2.
* List item 3.
Force end of list:
[]
+------------------------------------------+
Verbatim text not contained in list item 3
+------------------------------------------+
[[1]] Numbered item 1.
[[A]] Numbered item A.
[[B]] Numbered item B.
[[2]] Numbered item 2.
List numbering schemes: [[1]], [[a]], [[A]], [[i]], [[I]].
[Defined term 1] of definition list.
[Defined term 2] of definition list.
+-------------------------------+
Verbatim text
in a box
+-------------------------------+
--- instead of +-- suppresses the box around verbatim text.
[Figure name] Figure caption
*----------*--------------+----------------:
| Centered | Left-aligned | Right-aligned |
| cell 1,1 | cell 1,2 | cell 1,3 |
*----------*--------------+----------------:
| cell 2,1 | cell 2,2 | cell 2,3 |
*----------*--------------+----------------:
Table caption
No grid, no caption:
*-----*------*
cell | cell
*-----*------*
cell | cell
*-----*------*
Horizontal line:
=======================================================================
^L
New page.
<Italic> font. <<Bold>> font. <<<Monospaced>>> font.
{Anchor}. Link to {{anchor}}. Link to {{http://www.pixware.fr}}.
Link to {{{anchor}showing alternate text}}.
Link to {{{http://www.pixware.fr}Pixware home page}}.
Force line\
break.
Non\ breaking\ space.
Escaped special characters: \~, \=, \-, \+, \*, \[, \], \<, \>, \{, \}, \\.
Copyright symbol: \251, \xA9, \u00a9.
~~Commented out.
------------------------------------------------------------------------------

16
maven-site/my-app/src/site/apt/index.apt
View File

@ -1,16 +0,0 @@
-----
The Site
-----
The Maven Team
-----
Maven Site for your project
Congratulations! If you are looking at this page then you have successfully generated a
template site employing the site archetype and you have run:
+-----+
m2 site:site
+-----+

25
maven-site/my-app/src/site/fml/faq.fml
View File

@ -1,25 +0,0 @@
<?xml version="1.0"?>
<faqs id="General FAQ">
<part id="General">
<faq id="where">
<question>Where did Maven come from?</question>
<answer>
<p>
Maven was created by a group of software developers who were tired
of wasting their time fiddling around with builds and wanted to get
down to brass tacks and actually develop software!
</p>
</answer>
</faq>
<faq id="why">
<question>Why is maven so wildly popular?</question>
<answer>
<p>
Maven saves you so much time in your software development efforts that
you will have time to learn a second language, relax ten hours a
day, and train for that marathon you've always wanted to run!
</p>
</answer>
</faq>
</part>
</faqs>

596
maven-site/my-app/src/site/fr/apt/format.apt
View File

@ -1,596 +0,0 @@
Le format APT
~~~~~~~~~~~~~
Dans la section suivante, les boîtes contenant du texte dans la police
de type machine à écrire sont des exemples de source APT.
* Structure du document
~~~~~~~~~~~~~~~~~~~~~~~
A short APT document is contained in a single text file. A longer document
may be contained in a ordered list of text files. For instance, first text
file contains section 1, second text file contains section 2, and so on.
[Note:] Splitting the APT document in several text files on a section
boundary is not mandatory. The split may occur anywhere.
However doing so is recommended because a text file containing a
section is by itself a valid APT document.
A file contains a sequence of paragraphs and ``displays'' (non paragraphs
such as tables) separated by open lines.
A paragraph is simply a sequence of consecutive text lines.
+------------------------------------------------------------------------+
First line of first paragraph.
Second line of first paragraph.
Third line of first paragraph.
Line 1 of paragraph 2 (separated from first paragraph by an open line).
Line 2 of paragraph 2.
+------------------------------------------------------------------------+
The indentation of the first line of a paragraph is the main method used by
an APT processor to recognize the type of the paragraph. For example, a
section title must not be indented at all.
A ``plain'' paragraph must be indented by a certain amount of space. For
example, a plain paragraph which is not contained in a list may be indented
by two spaces.
+-------------------------------------------------+
My section title (not indented).
My paragraph first line (indented by 2 spaces).
+-------------------------------------------------+
Indentation is not rigid. Any amount of space will do. You don't even need
to use a consistent indentation all over your document. What really matters
for an APT processor is whether the paragraph is not indented at all or,
when inside a list, whether a paragraph is more or less indented than the
first item of the list (more about this later).
+-------------------------------------------------------+
First paragraph has its first line indented by four
spaces. Then the author did even bother to indent the
other lines of the paragraph.
Second paragraph contains several lines which are all
indented by two spaces. This style is much nicer than
the one used for the previous paragraph.
+-------------------------------------------------------+
Note that tabs are expanded with a tab width set to 8.
* Document elements
~~~~~~~~~~~~~~~~~~~
** Block level elements
~~~~~~~~~~~~~~~~~~~~~~~
*** Title
~~~~~~~~~~
A title is optional. If used, it must appear as the first block of the
document.
+----------------------------------------------------------------------------+
------
Title
------
Author
------
Date
+----------------------------------------------------------------------------+
A title block is indented (centering it is nicer). It begins with a line
containing at least 3 dashes (<<<--->>>).
After the first <<<--->>> line, one or several consecutive lines of text
(implicit line break after each line) specify the title of the document.
This text may immediately be followed by another <<<--->>> line and one or
several consecutive lines of text which specifies the author of the
document.
The author sub-block may optionaly be followed by a date sub-block using the
same syntax.
The following example is used for a document with an title and a date but
with no declared author.
+----------------------------------------------------------------------------+
------
Title
------
------
Date
------
+----------------------------------------------------------------------------+
The last line is ignored. It is just there to make the block nicer.
*** Paragraph
~~~~~~~~~~~~~
Paragraphs other than the title block may appear before the first section.
+----------------------+
Paragraph 1, line 1.
Paragraph 1, line 2.
Paragraph 2, line 1.
Paragraph 2, line 2.
+----------------------+
Paragraphs are indented. They have already been described in the {{document
structure}} section.
*** Section
~~~~~~~~~~~
Sections are created by inserting section titles into the document. Simple
documents need not contain sections.
+-----------------------------------+
Section title
* Sub-section title
** Sub-sub-section title
*** Sub-sub-sub-section title
**** Sub-sub-sub-sub-section title
+-----------------------------------+
Section titles are not indented. A sub-section title begins with one
asterisk (<<<*>>>), a sub-sub-section title begins with two asterisks
(<<<**>>>), and so forth up to four sub-section levels.
*** List
~~~~~~~~
+---------------------------------------+
* List item 1.
* List item 2.
Paragraph contained in list item 2.
* Sub-list item 1.
* Sub-list item 2.
* List item 3.
+---------------------------------------+
List items are indented and begin with a asterisk (<<<*>>>).
Plain paragraphs more indented than the first list item are nested in that
list. Displays such as tables (not indented) are always nested in the
current list.
To nest a list inside a list, indent its first item more than its parent
list. To end a list, add a paragraph or list item less indented than the
current list.
Section titles always end a list. Displays cannot end a list but the
<<<[]>>> pseudo-element may be used to force the end of a list.
+------------------------------------+
* List item 3.
Force end of list:
[]
--------------------------------------------
Verbatim text not contained in list item 3
--------------------------------------------
+------------------------------------+
In the previous example, without the <<<[]>>>, the verbatim text (not
indented as all displays) would have been contained in list item 3.
A single <<<[]>>> may be used to end several nested lists at the same
time. The indentation of <<<[]>>> may be used to specify exactly which
lists should be ended. Example:
+------------------------------------+
* List item 1.
* List item 2.
* Sub-list item 1.
* Sub-list item 2.
[]
-------------------------------------------------------------------
Verbatim text contained in list item 2, but not in sub-list item 2
-------------------------------------------------------------------
+------------------------------------+
There are three kind of lists, the bulleted lists we have already described,
the numbered lists and the definition lists.
+-----------------------------------------+
[[1]] Numbered item 1.
[[A]] Numbered item A.
[[B]] Numbered item B.
[[2]] Numbered item 2.
+-----------------------------------------+
A numbered list item begins with a label beetween two square brackets. The
label of the first item establishes the numbering scheme for the whole list:
[<<<[[1\]\]>>>] Decimal numbering: 1, 2, 3, 4, etc.
[<<<[[a\]\]>>>] Lower-alpha numbering: a, b, c, d, etc.
[<<<[[A\]\]>>>] Upper-alpha numbering: A, B, C, D, etc.
[<<<[[i\]\]>>>] Lower-roman numbering: i, ii, iii, iv, etc.
[<<<[[I\]\]>>>] Upper-roman numbering: I, II, III, IV, etc.
The labels of the items other than the first one are ignored. It is
recommended to take the time to type the correct label for each item in
order to keep the APT source document readable.
+-------------------------------------------+
[Defined term 1] of definition list 2.
[Defined term 2] of definition list 2.
+-------------------------------------------+
A definition list item begins with a defined term: text between square
brackets.
*** Verbatim text
~~~~~~~~~~~~~~~~~
+----------------------------------------+
----------------------------------------
Verbatim
text,
preformatted,
escaped.
----------------------------------------
+----------------------------------------+
A verbatim block is not indented. It begins with a non indented line
containing at least 3 dashes (<<<--->>>). It ends with a similar line.
<<<+-->>> instead of <<<--->>> draws a box around verbatim text.
Like in HTML, verbatim text is preformatted. Unlike HTML, verbatim text is
escaped: inside a verbatim display, markup is not interpreted by the APT
processor.
*** Figure
~~~~~~~~~~
+---------------------------+
[Figure name] Figure caption
+---------------------------+
A figure block is not indented. It begins with the figure name between
square brackets. The figure name is optionally followed by some text: the
figure caption.
The figure name is the pathname of the file containing the figure but
without an extension. Example: if your figure is contained in
<<</home/joe/docs/mylogo.jpeg>>>, the figure name is
<<</home/joe/docs/mylogo>>>.
If the figure name comes from a relative pathname (recommended practice)
rather than from an absolute pathname, this relative pathname is taken to be
relative to the directory of the current APT document (a la HTML)
rather than relative to the current working directory.
Why not leave the file extension in the figure name? This is better
explained by an example. You need to convert an APT document to PostScript
and your figure name is <<</home/joe/docs/mylogo>>>. A APT processor will
first try to load <<</home/joe/docs/mylogo.eps>>>. When the desired format
is not found, a APT processor tries to convert one of the existing
formats. In our example, the APT processor tries to convert
<<</home/joe/docs/mylogo.jpeg>>> to encapsulated PostScript.
*** Table
~~~~~~~~~
A table block is not indented. It begins with a non indented line containing
an asterisk and at least 2 dashes (<<<*-->>>). It ends with a
similar line.
The first line is not only used to recognize a table but also to specify
column justification. In the following example,
* the second asterisk (<<<*>>>) is used to specify that column 1 is
centered,
* the plus sign (<<<+>>>) specifies that column 2 is left aligned,
* the colon (<<<:>>>) specifies that column 3 is right aligned.
[]
+---------------------------------------------+
*----------*--------------+----------------:
| Centered | Left-aligned | Right-aligned |
| cell 1,1 | cell 1,2 | cell 1,3 |
*----------*--------------+----------------:
| cell 2,1 | cell 2,2 | cell 2,3 |
*----------*--------------+----------------:
Table caption
+---------------------------------------------+
Rows are separated by a non indented line beginning with <<<*-->>>.
An optional table caption (non indented text) may immediately follow the
table.
Rows may contain single line or multiple line cells. Each line of cell text
is separated from the adjacent cell by the pipe character (<<<|>>>).
(<<<|>>> may be used in the cell text if quoted: <<<\\|>>>.)
The last <<<|>>> is only used to make the table nicer. The first <<<|>>> is
not only used to make the table nicer, but also to specify that a grid is to
be drawn around table cells.
The following example shows a simple table with no grid and no caption.
+---------------+
*-----*------*
cell | cell
*-----*------*
cell | cell
*-----*------*
+---------------+
*** Horizontal rule
~~~~~~~~~~~~~~~~~~~
+---------------------+
=====================
+---------------------+
A non indented line containing at least 3 equal signs (<<<===>>>).
*** Page break
~~~~~~~~~~~~~~
+---+
^L
+---+
A non indented line containing a single form feed character (Control-L).
** Text level elements
~~~~~~~~~~~~~~~~~~~~~~
*** Font
~~~~~~~~
+-----------------------------------------------------+
<Italic> font. <<Bold>> font. <<<Monospaced>>> font.
+-----------------------------------------------------+
Text between \< and > must be rendered in italic. Text between \<\< and >>
must be rendered in bold. Text between \<\<\< and >>> must be rendered using
a monospaced, typewriter-like font.
Font elements may appear anywhere except inside other font elements.
It is not recommended to use font elements inside titles, section titles,
links and defined terms because a APT processor automatically applies
appropriate font styles to these elements.
*** Anchor and link
~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------+
{Anchor}. Link to {{anchor}}. Link to {{http://www.pixware.fr}}.
Link to {{{anchor}showing alternate text}}.
Link to {{{http://www.pixware.fr}Pixware home page}}.
+-----------------------------------------------------------------+
Text between curly braces (<<<\{}>>>) specifies an anchor. Text between
double curly braces (<<<\{\{}}>>>) specifies a link.
It is an error to create a link element that does not refer to an anchor of
the same name. The name of an anchor/link is its text with all non
alphanumeric characters stripped.
This rule does not apply to links to <external> anchors. Text beginning
with <<<http:/>>>, <<<https:/>>>, <<<ftp:/>>>, <<<file:/>>>, <<<mailto:>>>,
<<<../>>>, <<<./>>> (<<<..\\>>> and <<<.\\>>> on Windows) is recognized as
an external anchor name.
When the construct <<\{\{\{>><name><<}>><text><<}}>> is used, the link text
<text> may differ from the link name <name>.
Anchor/link elements may appear anywhere except inside other anchor/link
elements.
Section titles are implicitly defined anchors.
*** Line break
~~~~~~~~~~~~~~
+-------------+
Force line\
break.
+-------------+
A backslash character (<<<\\>>>) followed by a newline character.
Line breaks must not be used inside titles and tables (which are line
oriented blocks with implicit line breaks).
*** Non breaking space
~~~~~~~~~~~~~~~~~~~~~~
+----------------------+
Non\ breaking\ space.
+----------------------+
A backslash character (<<<\\>>>) followed by a space character.
*** Special character
~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------+
Escaped special characters: \~, \=, \-, \+, \*, \[, \], \<, \>, \{, \}, \\.
+---------------------------------------------------------------------------+
In certain contexts, these characters have a special meaning and therefore
must be escaped if needed as is. They are escaped by adding a backslash in
front of them. The backslash may itself be escaped by adding another
backslash in front of it.
Note that an asterisk, for example, needs to be escaped only if its begins a
paragraph. (<<<*>>> has no special meaning in the middle of a paragraph.)
+--------------------------------------+
Copyright symbol: \251, \xA9, \u00a9.
+--------------------------------------+
Latin-1 characters (whatever is the encoding of the APT document) may be
specified by their codes using a backslash followed by one to three octal
digits or by using the <<<\x>>><NN> notation, where <NN> are two hexadecimal
digits.
Unicode characters may be specified by their codes using the <<<\u>>><NNNN>
notation, where <NNNN> are four hexadecimal digits.
*** Comment
~~~~~~~~~~~
+---------------+
~~Commented out.
+---------------+
Text found after two tildes (<<<\~~>>>) is ignored up to the end of line.
A line of <<<~>>> is often used to ``underline'' section titles in order to
make them stand out of other paragraphs.
* The APT format at a glance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------------------------------------------------------
------
Title
------
Author
------
Date
Paragraph 1, line 1.
Paragraph 1, line 2.
Paragraph 2, line 1.
Paragraph 2, line 2.
Section title
* Sub-section title
** Sub-sub-section title
*** Sub-sub-sub-section title
**** Sub-sub-sub-sub-section title
* List item 1.
* List item 2.
Paragraph contained in list item 2.
* Sub-list item 1.
* Sub-list item 2.
* List item 3.
Force end of list:
[]
+------------------------------------------+
Verbatim text not contained in list item 3
+------------------------------------------+
[[1]] Numbered item 1.
[[A]] Numbered item A.
[[B]] Numbered item B.
[[2]] Numbered item 2.
List numbering schemes: [[1]], [[a]], [[A]], [[i]], [[I]].
[Defined term 1] of definition list.
[Defined term 2] of definition list.
+-------------------------------+
Verbatim text
in a box
+-------------------------------+
--- instead of +-- suppresses the box around verbatim text.
[Figure name] Figure caption
*----------*--------------+----------------:
| Centered | Left-aligned | Right-aligned |
| cell 1,1 | cell 1,2 | cell 1,3 |
*----------*--------------+----------------:
| cell 2,1 | cell 2,2 | cell 2,3 |
*----------*--------------+----------------:
Table caption
No grid, no caption:
*-----*------*
cell | cell
*-----*------*
cell | cell
*-----*------*
Horizontal line:
=======================================================================
^L
New page.
<Italic> font. <<Bold>> font. <<<Monospaced>>> font.
{Anchor}. Link to {{anchor}}. Link to {{http://www.pixware.fr}}.
Link to {{{anchor}showing alternate text}}.
Link to {{{http://www.pixware.fr}Pixware home page}}.
Force line\
break.
Non\ breaking\ space.
Escaped special characters: \~, \=, \-, \+, \*, \[, \], \<, \>, \{, \}, \\.
Copyright symbol: \251, \xA9, \u00a9.
~~Commented out.
------------------------------------------------------------------------------

17
maven-site/my-app/src/site/fr/apt/index.apt
View File

@ -1,17 +0,0 @@
-----
Le Site
-----
L'équipe Maven
-----
Site Maven pour votre projet
Félicitations! Si vous regardez cette page alors vous avez
généré avec succès un modèle de site en utilisant l'archétype
de site et vous avez lancé :
+-----+
m2 site:site
+-----+

25
maven-site/my-app/src/site/fr/fml/faq.fml
View File

@ -1,25 +0,0 @@
<?xml version="1.0"?>
<faqs id="FAQ Général">
<part id="General">
<faq id="where">
<question>D'où vient Maven</question>
<answer>
<p>
Maven was created by a group of software developers who were tired
of wasting their time fiddling around with builds and wanted to get
down to brass tacks and actually develop software!
</p>
</answer>
</faq>
<faq id="why">
<question>Pourquoi Maven est-il si populaire?</question>
<answer>
<p>
Maven saves you so much time in your software development efforts that
you will have time to learn a second language, relax ten hours a
day, and train for that marathon you've always wanted to run!
</p>
</answer>
</faq>
</part>
</faqs>

15
maven-site/my-app/src/site/fr/xdoc/xdoc.xml
View File

@ -1,15 +0,0 @@
<?xml version="1.0"?>
<document>
<properties>
<title>Bienvenue</title>
<author email="dev@maven.apache.org">The Maven Team</author>
</properties>
<body>
<section name="Bienvenue dans un fichier XDOC!">
<p>
Ceci est du texte pour le fichier xdoc.
</p>
</section>
</body>
</document>

24
maven-site/my-app/src/site/site.xml
View File

@ -1,24 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
<bannerLeft>
<name>Maven</name>
<src>http://maven.apache.org/images/apache-maven-project.png</src>
<href>http://maven.apache.org/</href>
</bannerLeft>
<bannerRight>
<src>http://maven.apache.org/images/maven-small.gif</src>
</bannerRight>
<body>
<links>
<item name="Apache" href="http://www.apache.org/" />
<item name="Maven 1.0" href="http://maven.apache.org/"/>
<item name="Maven 2" href="http://maven.apache.org/maven2/"/>
</links>
<menu name="Maven 2.0">
<item name="APT Format" href="format.html"/>
<item name="FAQ" href="faq.html"/>
<item name="Xdoc Example" href="xdoc.html"/>
</menu>
</body>
</project>

24
maven-site/my-app/src/site/site_fr.xml
View File

@ -1,24 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
<bannerLeft>
<name>Maven</name>
<src>http://maven.apache.org/images/apache-maven-project.png</src>
<href>http://maven.apache.org/</href>
</bannerLeft>
<bannerRight>
<src>http://maven.apache.org/images/maven-small.gif</src>
</bannerRight>
<body>
<links>
<item name="Apache" href="http://www.apache.org/" />
<item name="Maven 1.0" href="http://maven.apache.org/"/>
<item name="Maven 2" href="http://maven.apache.org/maven2/"/>
</links>
<menu name="Maven 2.0">
<item name="Format APT" href="format.html"/>
<item name="FAQ" href="faq.html"/>
<item name="Exemple Xdoc" href="xdoc.html"/>
</menu>
</body>
</project>

15
maven-site/my-app/src/site/xdoc/xdoc.xml
View File

@ -1,15 +0,0 @@
<?xml version="1.0"?>
<document>
<properties>
<title>Welcome</title>
<author email="dev@maven.apache.org">The Maven Team</author>
</properties>
<body>
<section name="Welcome to an XDOC file!">
<p>
This is some text for the xdoc file.
</p>
</section>
</body>
</document>

38
maven-site/my-app/src/test/java/com/mycompany/app/AppTest.java
View File

@ -1,38 +0,0 @@
package com.mycompany.app;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
/**
* Unit test for simple App.
*/
public class AppTest
extends TestCase
{
/**
* Create the test case
*
* @param testName name of the test case
*/
public AppTest( String testName )
{
super( testName );
}
/**
* @return the suite of tests being tested
*/
public static Test suite()
{
return new TestSuite( AppTest.class );
}
/**
* Rigourous Test :-)
*/
public void testApp()
{
assertTrue( true );
}
}

0
maven-site/my-app/src/test/resources/test.properties
View File

38
maven-site/notes.txt
View File

@ -1,38 +0,0 @@
Brett Porter wrote:
> The active project changes during the reactor build. At the compile
> stage, it refers to the target/classes directory. At the package
> stage, it points to the jar file. If you are implementing your own
> packaging goal, you need to call project.getArtifact().setFile( ... )
> to ensure this is used.
- multi module howto
- per user scm setup
- outline behaviour when connection and developConnection are defined
Our current URL looks like:
scm:cvs:pserver:@cvs.host.name:/cvsroot:module-version
Using this URL, the default is to connect to the CVS server using the
same userid as the current user. This is the desired behavior and I
don't want to mess that up. I just would like a means to add a userid
in the URL only in special circumstances like Continuum.
We might want to do something where we say it is a best practice to
specify a ${user} and take it from the environment and allow an override.
- testing a plugin
- How to get started behind an NTLM proxy.
- How snapshots works
- How do i use the lifecycle provided by a plugin:
- How do i disable ibiblio
- using version ranges
- plugin expressions (look at bob allison's work)
- overriding the central repository (use central)
- description of what packagings are available and how they work
- creating upload bundles
- modello example
- changing the snapshot policy frequency
- overriding central repo
- using POM info in applications: the POM is packaged so there is acccess
continuum example to get the version.
- quick description of scm,wagon,continuum

49
maven-site/pom.xml
View File

@ -1,49 +0,0 @@
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<artifactId>maven</artifactId>
<groupId>org.apache.maven</groupId>
<version>2.0.1-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>maven-site</artifactId>
<name>Maven</name>
<url>http://maven.apache.org/maven2</url>
<inceptionYear>2001</inceptionYear>
<distributionManagement>
<site>
<id>website</id>
<!--
<url>scpexe://minotaur.apache.org/x1/home/jvanzyl/public_html/</url>
-->
<url>scpexe://minotaur.apache.org/www/maven.apache.org/</url>
</site>
</distributionManagement>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh-external</artifactId>
<version>1.0-alpha-5</version>
</extension>
</extensions>
</build>
<reporting>
<excludeDefaults>true</excludeDefaults>
<!-- TODO: disable dependencies -->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
</plugin>
</plugins>
</reporting>
<!-- repeated here so that maven-site is not appended -->
<scm>
<connection>scm:svn:http://svn.apache.org/repos/asf/maven/components/trunk/</connection>
<developerConnection>scm:svn:https://svn.apache.org/repos/asf/maven/components/trunk/</developerConnection>
<url>http://svn.apache.org/viewcvs.cgi/maven/components/trunk/</url>
</scm>
</project>

465
maven-site/src/site/apt/ant-tasks.apt
View File

@ -1,465 +0,0 @@
--------
Antlib for Maven 2.0
--------
Brett Porter
--------
24 June 2005
--------
Antlib for Maven 2.0
Maven 2.0 now comes with a set of Ant tasks that can be used to utilise Maven's artifact handling features
from within Ant. This includes:
* <Dependency management> - including transitive dependencies, scope recognition and SNAPSHOT handling
* <Artifact deployment> - file and SSH based deployment to a Maven repository
* <POM processing> - for reading a Maven 2.0 <<<pom.xml>>> file
The Ant tasks can be downloaded from {{{download.html#ant} Maven 2.0 download page}}.
Installing the Ant Tasks
For convenience, the Ant task and all its dependencies are packaged together as a single JAR file.
There are two ways to use the tasks from your scripts.
* Intalling in Ant's <<<lib>>> directory
This is the simplest installation method but requires changes on every machine using the build file.
You can place the JAR in your Ant <<<lib>>> directory, include it in the <<<CLASSPATH>>> environment variable,
or pass it in to Ant using the <<<-lib>>> command line parameter.
Using this method, to make the tasks available in your build file, add the following namespace to the start of
the file:
-----
<project ... xmlns:artifact="antlib:org.apache.maven.artifact.ant">
...
-----
* Declaring a <<<typedef>>>
Using a <<<typedef>>> declaration allows you to store the library anywhere you like (such as source control)
and put it's location in the build file. This can be used to bootstrap the tasks by using <<<get>>> to obtain
the library, and then reference it from the build script.
The following example shows how to set it up, assuming the library is in the <<<lib>>> subdirectory of your current
project.
-----
<project ... xmlns:artifact="urn:maven-artifact-ant">
...
<typedef resource="org/apache/maven/artifact/ant/antlib.xml" uri="urn:maven-artifact-ant">
<classpath>
<pathelement location="lib/maven-artifact-ant-2.0-beta-1.jar" />
</classpath>
</typedef>
...
-----
Using the Antlib
* Declaring Dependencies
The main purpose of the antlib is to utilise Maven's {{{dependencies.html} dependency management features}}.
This is achieved with the <<<dependencies>>> task. The simplest usage involves specifying your dependencies inline,
such as in the following example:
-----
<artifact:dependencies pathId="dependency.classpath">
<dependency groupId="org.apache.maven.wagon" artifactId="wagon-provider-test"
version="1.0-alpha-2"/>
<dependency groupId="org.codehaus.modello" artifactId="modello-core"
version="1.0-alpha-2-SNAPSHOT"/>
<dependency groupId="javax.servlet" artifactId="servlet-api"
version="2.4" scope="provided" />
</artifact:dependencies>
-----
The above example will download those 3 dependencies, and their dependencies, and so on. They will be stored in
the default local repository location, <<<$\{user.home\}/.m2/repository>>>.
You can also use a Maven 2.0 POM to declare your dependencies, which is {{{#POM} explained below}}. This is a
recommended practice so that you can reuse the file to deploy your own artifacts.
You may have noticed the <<<pathId>>> reference. This is optional, but if given will create a classpath reference
that includes the local files downloaded as dependencies. This is usually used to pass to <<<javac>>> or other tasks:
-----
<javac ...>
<classpath refid="dependency.classpath" />
...
</javac>
-----
Another option you can use is <<<filesetId>>>, which will give you a fileset reference that can be used to copy
files into a particular location. For example, to populate <<<WEB-INF/lib>>> with your dependencies
you could use the following:
-----
<dependencies filesetId="dependency.fileset" useScope="runtime">
...
</dependencies>
<copy todir="${webapp.output}/WEB-INF/lib">
<fileset refid="dependency.fileset" />
<mapper type="flatten" />
</copy>
-----
Note the <<<useScope>>> attribute in this call. This ensures that your web application only includes your compile
and runtime dependencies, excluding those that are only for testing or are expected to already be provided in
the servlet container.
You can also specify a <<<scope>>> parameter on each dependency. This changes the behaviour of
transitive dependencies and is useful for building different types of classpaths. To see how it affects
the behaviour of the dependencies, see the {{{dependencies.html#Dependency_Scope} Dependency Mechanism}}
documentation in the Maven 2.0 site.
* Declaring Repositories
All of the tasks can optionally take one or more remote repositories to download from and upload to, and a
local repository to store downloaded and installed archives to.
These can be specified inline, or if you choose to reuse them, they can be declared with an <<<id>>>/<<<refid>>>
combination.
For example, you can specify the remote repository you want to use:
-----
<artifact:remoteRepository id="remote.repository" url="http://repository.mycompany.com/" />
...
<artifact:dependencies>
...
<remoteRepository refid="remote.repository" />
</artifact:dependencies>
-----
If no remote repositories are specified, the default {{{http://repo1.maven.org/maven2} http://repo1.maven.org/maven2}}
is used.
<<Note:>> to work with transitive dependencies, you <must> use a Maven 2.0 repository.
If your repository requires authentication, you can provide this as a nested element. It accepts the
attributes <<<username>>>, <<<password>>>, and for SSH based repositories <<<privateKey>>>
and <<<passphrase>>>. For example:
-----
<authentication username="brett" privateKey="${user.home}/.ssh/id_dsa" />
-----
* Installing and Deploying Your Own Artifacts
If you want to share your built artifacts between projects, you can use two other tasks: <<<install>>> for
placing them in your local repository for access as dependencies in other scripts, and <<<deploy>>> for
deploying them to an remote location you have set up to serve as a repository in your organisation.
Note that the installation and deployment require that you have a Maven 2.0 POM file to deploy along with it.
These are required for the transitive dependency mechanism to work effectively, and can be quite simple to
create.
-----
...
<artifact:pom id="maven.project" file="pom.xml" />
<artifact:install file="target/maven-artifact-ant-2.0-alpha-3.jar">
<pom refid="maven.project"/>
</artifact:install>
<artifact:deploy file="target/maven-artifact-ant-2.0-alpha-3.jar">
<remoteRepository url="file://localhost/www/repository"/>
<pom refid="maven.project"/>
</artifact:deploy>
...
-----
For deploying using a protocol other than local file system, you need to register a provider to make the other
protocols available. For example:
-----
...
<artifact:install-provider artifactId="wagon-ssh" version="1.0-alpha-5"/>
<artifact:deploy file="target/maven-artifact-ant-2.0-alpha-3.jar">
<remoteRepository url="scp://localhost/www/repository">
<authentication username="${repository.username}" privateKey="${user.home}/.ssh/id_dsa"/>
</remoteRepository>
<pom refid="maven.project"/>
</artifact:deploy>
...
-----
The currently available providers are:
*--------------+--------------------------+-------------------+
| Protocol | Artifact ID | Version |
*--------------+--------------------------+-------------------+
| <<<file>>> | <<<wagon-file>>> | <<<1.0-alpha-5>>> |
*--------------+--------------------------+-------------------+
| <<<scp>>> | <<<wagon-ssh>>> | <<<1.0-alpha-5>>> |
*--------------+--------------------------+-------------------+
| <<<scpexe>>> | <<<wagon-ssh-external>>> | <<<1.0-alpha-5>>> |
*--------------+--------------------------+-------------------+
| <<<ftp>>> | <<<wagon-ftp>>> | <<<1.0-alpha-5>>> |
*--------------+--------------------------+-------------------+
* Using a Maven {POM} File
In Maven, the Project Object Model (POM) represents a unit of work - one exists for each artifact that is built.
Maven 2.0 POM files are required for deploying your own artifacts to a repository for use in the dependencies
elements of other projects.
They can also be reused for declaring your own dependencies, instead of specifying the inline version given earlier.
Here is the earlier example, expressed as a POM:
-----
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.project</groupId>
<artifactId>project-model</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-provider-api</artifactId>
<version>1.0-alpha-2</version>
</dependency>
<dependency>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-core</artifactId>
<version>1.0-alpha-2-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
-----
These elements represent:
* <modelVersion> - this is the version of the POM layout in use, currently <<<4.0.0>>>
* <groupId> - the group ID represents your organisation and project name, much like a Java package name.
This must be universally unique. This becomes the base directory in the repository as well.
* <artifactId> - the artifact ID represents the current build unit. It usually equals the filename of the
resulting file, and must be unique within the group.
* <version> - the version of the artifact you are building.
* <dependencies> - the artifacts the project is dependant on.
This is all that is required for most projects. However, it is also possible to use other fields available in
Maven to describe your project, and reference them from your build script.
To access a POM as Ant properties, you must define it as a reference. For example, to access the version from a POM,
you could use the following:
-----
<artifact:pom id="maven.project" file="pom.xml" />
<echo>The version is ${maven.project.version}</echo>
-----
You can also access nested parts of the POM. For example, you can read the default value of the <<<directory>>>
element within the <<<build>>> element using a <<<.>>> separator.
-----
<artifact:pom id="project" file="pom.xml" />
<echo>The version is ${project.build.directory}</echo>
-----
For more information on the elements available in the POM, see the {{{maven-model/maven.html} descriptor reference}}.
The Settings File
The POM can be used to represent most of the information that the tasks have access to, including remote
repositories. For information that is user or environment specific, such as the <<<authentication>>> tag, are
specified in the <<<settings.xml>>> file in Maven, and can be accessed from the Ant tasks also.
The file is first looked for in <<<$\{user.home\}/.ant/settings.xml>>>, then in <<<$\{user.home\}/.m2/settings.xml>>>
so that the settings can be shared with Maven 2.0 itself.
For example, to specify your proxy settings, you would specify the following <<<settings.xml>>> file:
-----
<settings>
<proxies>
<proxy>
<protocol>http</protocol>
<host>proxy.host.net</host>
<port>8080</port>
<nonProxyHosts>localhost</nonProxyHosts>
</proxy>
</proxies>
</settings>
-----
For more information in configuring <<<settings.xml>>>, see:
* {{{configuration.html} Configuring Maven}}.
* {{{maven-settings/settings.html} Settings Descriptor Reference}}.
* There is a
{{{http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/conf/settings.xml} sample settings file}}
in the Maven installation.
Sample Ant Script
The file
{{{http://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact-ant/sample.build.xml} sample.build.xml}}
is a sample Ant script showing some of the functionality in action.
Getting Help
If you have any questions specific to the Ant tasks, please contact the
{{{mail-lists.html} Maven Users Mailing List}}.
For more on the Maven functionality behind them, try the following links:
* {{{dependencies.html} Dependency Mechanism}}
* {{{maven-settings/settings.html} Settings Reference}}
* {{{maven-model/maven.html} POM Reference}}
Task Reference
* <<<dependencies>>>
This task will check if any of the specified dependencies, and their dependencies are missing or updated, and
download them if necessary. The dependencies will be made available as a fileset or path reference.
The dependencies task accepts the following attributes:
*-----------------+--------------------------------------------------------+
| <<<verbose>>> | If <<<true>>> this displays the results of each dependency resolution and their relationships. Default is <false>.
*-----------------+--------------------------------------------------------+
| <<<filesetId>>> | The reference ID to store a fileset under of the resolved dependencies.
*-----------------+--------------------------------------------------------+
| <<<pathId>>> | The reference ID to store a path under of the resolved dependencies.
*-----------------+--------------------------------------------------------+
The task can include the <<<dependency>>> nested type, in addition to the other shared types explained later.
You must include at least one <<<dependency>>> element, or a single <<<pom>>> element, but not both.
** <<<dependency>>>
*------------------+--------------------------------------------------------+
| <<<groupId>>> | The group ID for of the dependency. <Required>
*------------------+--------------------------------------------------------+
| <<<artifactId>>> | The artifact ID for of the dependency. <Required>
*------------------+--------------------------------------------------------+
| <<<version>>> | The version of the dependency. <Required>
*------------------+--------------------------------------------------------+
| <<<type>>> | The type of the dependency. The default is <<<jar>>>.
*------------------+--------------------------------------------------------+
| <<<scope>>> | The scope of the usage of the dependency, which affects which of its dependencies are also retrieved. This can be <<<compile>>>, <<<runtime>>>, <<<test>>>, <<<provided>>>.
*------------------+--------------------------------------------------------+
The dependency can also nest multiple <<<exclusion>>> elements.
*** <<<exclusion>>>
An exclusion can be used to prevent the resolution of a particular artifact in the tree of the dependency.
*------------------+--------------------------------------------------------+
| <<<groupId>>> | The group ID for of the dependency to exclude. <Required>
*------------------+--------------------------------------------------------+
| <<<artifactId>>> | The artifact ID for of the dependency to exclude. <Required>
*------------------+--------------------------------------------------------+
* <<<install>>>
This task will install the given file into the local repository. It is stored using the information in the supplied
POM.
*------------------+--------------------------------------------------------+
| <<<file>>> | The file to install in the local repository. <Required>
*------------------+--------------------------------------------------------+
The task must also take a nested <<<pom>>>, and can have an optional <<<localRepository>>> element.
* <<<deploy>>>
This task will deploy the given file into the remote repository. It is stored using the information in the supplied
POM.
*------------------+--------------------------------------------------------+
| <<<file>>> | The file to deploy in the remote repository. <Required>
*------------------+--------------------------------------------------------+
The task must also take a nested <<<pom>>>, and can have an optional <<<remoteRepository>>> element. If no
<<<remoteRepository>>> element is given, the <<<distributionManagement>>> section of the POM is used.
Type Reference
* <<<localRepository>>>
Specifies the location of the local repository of artifacts.
*------------------+--------------------------------------------------------+
| <<<location>>> | The directory of the local repository. <Required>
*------------------+--------------------------------------------------------+
| <<<layout>>> | The layout of the local repository. The valid options are <<<legacy>>> (Maven 1), or <<<default>>> (Maven 2).
*------------------+--------------------------------------------------------+
* <<<remoteRepository>>>
Specifies the location of the remote repository.
*----------------------+--------------------------------------------------------+
| <<<url>>> | The URL of the repository. <Required>
*----------------------+--------------------------------------------------------+
| <<<layout>>> | The layout of the remote repository. The valid options are <<<legacy>>> (Maven 1), or <<<default>>> (Maven 2).
*----------------------+--------------------------------------------------------+
| <<<snapshots>>> | Policies regarding downloading snapshot artifacts.
*----------------------+--------------------------------------------------------+
| <<<releases>>> | Policies regarding downloading released artifacts.
*----------------------+--------------------------------------------------------+
* <<<snapshots>>>, <<<releases>>>
Policies about downloading each type of artifact.
*----------------------+--------------------------------------------------------+
| <<<enabled>>> | Whether to download this type of artifact from the repository. Default is <<<true>>>.
*----------------------+--------------------------------------------------------+
| <<<updatePolicy>>> | How often to check for updates on dependencies with that are snapshots or include a range of versions. Valid values are <<<never>>>, <<<interval:MINUTES>>>, <<<daily>>> (<default)>, <<<always>>>.
*----------------------+--------------------------------------------------------+
| <<<checksumPolicy>>> | How to treat missing or incorrect checksums for the dependencies that are downloaded. Valid values are <<<warn>>> (<default>) and <<<fail>>>.
*----------------------+--------------------------------------------------------+
The remote repository can also nest the following elements: <<<authentication>>> and <<<proxy>>>.
** <<<proxy>>>
The proxy element is typically used for HTTP repositories. The layout is the same as in the
{{{maven-settings/settings.html#Proxy} settings reference}}.
** <<<authentication>>>
The authentication element is used for passing a username, password and other credentials to the repository either
on upload or download. The layout is the same as in the {{{maven-settings/settings.html#Server} settings reference}}.
* <<<pom>>>
The POM element will load a POM file and make it available as a reference for the other tasks or as properties.
*------------------+--------------------------------------------------------+
| <<<file>>> | The file of the POM to load. <Required>
*------------------+--------------------------------------------------------+

167
maven-site/src/site/apt/articles.apt
View File

@ -1,167 +0,0 @@
------
Guide to the APT Format
------
Jason van Zyl
------
12 October 2005
------
Books on Maven
* Maven: A Developer's Notebook
* O'Reilly
* Vincent Massol, Tim O'Brien
* July 2005
Maven in the Press
Have written or would like to write a story on Maven? {{{../../mail-lists.html}Contact us}} on the developers mailing list.
* {{{http://www.internetnews.com/dev-news/article.php/3381841}Apache's Maven Comes of Age}} (Coverage of the release of Maven 1.0)
* internetnews.com
* Sean Michael Kerner
* 15 July 2004</td>
Articles on Maven
* {{{http://www.developer.com/open/article.php/10930_3552026_1}Taking the Maven 2 Plunge}}
* David DeWolf
* 1 October 2005
* {{{http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html}Building J2EE Projects with Maven}}
* Vincent Massol
* 7 September 2005
* {{{https://sydneyjug.dev.java.net/files/documents/922/15554/sjug20050601.pdf}Maven 2.0 and Continuum SJUG Presentation}}
* Brett Porter
* 1 June 2005
* {{{http://www-128.ibm.com/developerworks/opensource/library/os-maven/index.html}Exploiting Maven in Eclipse}}
* developerWorks
* Gilles Dodinet
* 24 May 2005
* {{{http://www-128.ibm.com/developerworks/websphere/library/techarticles/0503_boog/0503_boog.html?ca=dgr-lnxw09Maven}Managing WebSphere Portal V5.1 projects with Apache Maven and Rational Application Developer 6.0}}
* developerWorks
* Hinrich Boog
* 30 March 205
* {{{http://www.codehaus.org/~vmassol/blog/Maven%201.0%20-%2020041216.ppt}Maven 1.0 Javapolis Presentation}}
* Vincent Massol
* 16 December 2004
* {{{http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk2.html}Master and Commander by Julien Dubois}}
* Oracle
* Julien Dubois
* November 2004
* {{{http://www.manfred-wolff.de/Maven-short.pdf}installing and working with Maven (in German)}}
* Manfred Wolff
* August 2004
* {{{http://www.onjava.com/pub/a/onjava/2004/03/17/maven.html}Extending Maven Through Plugins by Eric Pugh}}
* OnJava
* Eric Pugh
* 17 March 2004
* {{{http://www.theserverside.com/articles/article.tss?l=MavenMagic}Maven Magic - a tutorial on Maven and J2EE projects.}}
* TheServerSide
* Srikanth Shenoy
* November 2003
* {{{http://www.jdocentral.com/JDO_Articles_20031117.html}JDO Meets Maven}}
* JDOCentral
* Andy Jefferson
* 17 November 2003
* {{{http://www.onjava.com/pub/a/onjava/2003/10/22/maven.html}Developing with Maven by Rob Herbst}}
* OnJava
* Rob Herbst
* 22 October 2003
* {{{http://www.devx.com/java/Article/17204}Apache Maven Simplifies the Java Build Process Even More Than Ant}}
* DevX
* Dave Ford
* 2 September 2003
* {{{http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf}Building J2EE applications with Maven (Slides from TheServerSide Symposium)}}
* TheServerSide
* Vincent Massol
* 27 June 2003
* {{{http://www.javaworld.com/javaworld/jw-10-2002/jw-1011-maven.html}Maven ties together tools for better code management}}
* JavaWorld
* Jeff Linwood
* 11 October 2002
* {{{http://www.javausergroup.at/events/maven.pdf}The Stairway to Maven}}
* Siegfried G<>SCHL
* 26 June 2002
* {{{http://wiki.astrogrid.org/bin/view/Astrogrid/MakingWarWithMaven}How to get Maven to build your web service into a WAR on AstroGrid}}
* Astrogrid
* {{{http://wiki.astrogrid.org/bin/view/Astrogrid/MavenFAQ}Some Maven FAQs on AstroGrid}}
* Astrogrid
* {{{http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes}Some Useful Maven Notes on AstroGrid}}
* Astrogrid
* {{{http://etudiant.univ-mlv.fr/~mvongvil/Maven_Intro.html}An Introduction to Maven</a> (in French).}}
* {{{http://hotwork.sourceforge.net/hotwork/manual/maven/index.html}A tutorial for Maven, J2EE projects, and MevenIDE}} (in Portuguese).
If you are writing an article on Maven we suggest contacting the developers on the mailing list as we would be happy
to provide feedback to help ensure accuracy in your artiticle. Just ping us on the {{mail-lists.html}dev mailing list}}
to get in touch.

99
maven-site/src/site/apt/background/history-of-maven.apt
View File

@ -1,99 +0,0 @@
------
History of Maven
------
Jason van Zyl
------
12 October 2005
------
History of Maven by Jason van Zyl
Maven began its life in the {{{http://jakarta.apache.org}Jakarta}} {{{ http://jakarta.apache.org/alexandria/legacy/}Alexandria}}
project. The Alexandria project is now defunct but was the breeding ground for not only Maven, but for the
{{{http://gump.apache.org}Gump}} and {{{http://forrest.apache.org}Forrest}} projects as well. From the old
{{{http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/maven/?hideattic=0}CVS}} archive
you can see that as of the date of this document Maven was removed from Alexandria about 3 years, 7 months ago
making Maven about 4 years old! Maven spent about 5 months as part of the Alexandria before moving on to its next home
in the {{{http://jakarta.apache.org/turbine}Turbine}} project.
Though Maven started in Alexandria the test bed for its use was the Turbine project. Turbine was in the process of
decoupling its persistence layer, services layer and web layer into separate builds and I got very tired of having
to maintain several different builds which were essentially the same. There was no way to easy template Ant builds
in those days and every ant build appeared to be different and I found this incredibly frustrating and futile. I figured
who really cares how the build works so long as it works and is easy to use. The infrastructure of a project is
incredibly important but the value of a project lies in the application being developed. As such the build is
generally neglected and tends to fall apart when you need it to work most like when you need to prepare a release or when
more then a couple of people are working on the project. In Jakarta land four years ago it was rare that a Ant build
worked out of the box. Mind you many Turbine developers suffered as I tried to get Maven working which is something I regret,
but I figure how do new projects start and survive if someone doesn's suffer. I figured it was for their own good
(I've been known to have an opinion or two) and after much gnashing of teeth I think Maven has finally come of age.
It reminds me of one of my favourite quotes from Ralph Johnson and Don Roberts in Patterns for Evolving Frameworks:
<People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction
on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a
resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.>
I didn't really know what the final result would look like I just knew there had to be a better way.
But to start with I know I wanted:
* <<A model for a project>> so you could look in one place for everything that pertained to the project
* <<A standard directory structure>> so you didn't have to go fishing around for libraries, sources and documentation
[]
So started using a model with a simple XML representation and picked what I thought were some decent standards for
a directory structure and that's how it started. I was still using Ant under the covers but I had some standard targets
that could be used in each of the Turbine builds and that made me happy.
As noted above one of the projects in Alexandria at the time was Gump. Sam Ruby tried to convince me that using
the Gump model would be a good idea so I took a look. After taking a look at the descriptors I noted that Gump
pretty much allowed any project to do whatever it wanted in terms of directory structure, use of JARs in CVS,
multiple artifacts per project, documentation splayed everywhere, and several other things that made no sense to me
as Gump was not trying to standardize anything at the time but trying to continously integrate anything it could
get its hands on. My goals were different and I wanted to make an
{{{http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html}opinionated}} piece
of software and I preferred the notion of convention over configuration. I wanted a project's infrastructure to
look the same and work the same so I continued to pursue my own model for a project and decided to disagree with
Gump's particular tact at project modelling which I thought was too flexible. I wanted to save people time by being
able to find things in the same place. Again the value in a project is the final result: how it is constructed
and built predictable and easy. I fully admit some warts in Maven 1.x sometimes made things harder but that is
par for the course with first generation tools.
The next thing I noticed were all the JARs that we were depending on were stored in CVS. We had many copies
of Xerces laying around which is a waste of space, every time the version of Xerces changed
I had to update the copies of Xerces in each of the projects, but more importantly without some declarative statement of
your dependencies there is no way you could perform any analysis. People tend to miss the point entirely regarding
a declaritive dependency use. People say it's so easy just to store their dependencies in an SCM but try decomposing
your big crappy build into components to encourage resuse and ease of maintenace, or try to analyse what you might
need at runtime between all your different apps with commons dependencies in the graph and you're shit out of luck.
The true power of declaritive dependencies lies not in the fact that you can save a few bytes of disk space, though
it can really add up if you're not careful, but in the analsys that can be performed. Once you have a decent graph
all sorts of things are possible. Back to history: so now that declarative dependencies existed it needed to
be easier ...
This is when I decided to employ standard Java-like inheritance in the model used and find a way to create a repository
for things you need to build. So I hacked in some inheritance goop and now it was time for the repository. I asked
around Apache to see if it would be possible to host a repository and soon found out that it was not possible to
host non-Apache-like artifacts. So LGPL and GPL artifacts were out which didn't really make for a useful repository.
After a little hunting I found {{{http://www.ibiblio.org}Ibiblio}} which is a vast archive of all sorts of neat
stuff including tons of free software. One of the mandates of Ibiblio is to aid in the dispersal of free software.
Sounded perfect to me so I got in contact with John Reuning at Ibiblio and the rest is history. Working with the
folks at Ibiblio has been a pleasure, the admins there are an amazingly helpful and talented bunch. They let us
store whatever free software we want, provide great stats, and will let us host any software we want. Ibiblio
is very cool.
Many people had some problems with Maven 1.x but it generally worked and all tools in their first generation
suffer from many short comings and the only way to overcome that is to forge ahead and try to create something
better the next time around. With all the feed back the Maven developers have received from 1.x users
and during the betas of 2.0 we think we've finally got something to build on. The first version of Maven
was written by myself with lots of help from Bob McWhirter
~~ jar jar
~~ ibiblio reasons
~~ maven top-level project
~~ use of jelly
~~ move toward 1.0
~~ development of m2
~~ present day

11
maven-site/src/site/apt/background/philosophy-of-maven.apt
View File

@ -1,11 +0,0 @@
------
Philosophy of Maven
------
Jason van Zyl
------
12 October 2005
------
Philosophy of Maven
~~I had a couple of slides on this in my javaZone presentation - trygve

150
maven-site/src/site/apt/benefits-of-using-maven.apt
View File

@ -1,150 +0,0 @@
-----
Benefits of using Maven
-----
Jason van Zyl
-----
12 October 2005
-----
Benefits of using Maven
*John Casey
[[1]]standardization
[[2]]reuse
[[3]]consistency wrt build output
[[4]]dependency management
[[5]]scalability (lower level of additional info/code to add a new step to the build process)
[]
*Ashley williams
[[1]]Dependency management
[[2]]Build lifecycle management
[[3]]Large existing repository
[[4]]Eclipse aware (sort of)
[[5]]Well documented (hopefully soon)
[]
*Eric Hartmann
[[1]]One directory layout,
[[2]]A single way to define dependencies,
[[3]]Setting up a project is really fast,
[[4]]99% of my needs are available out of the box,
[[5]]Transitive dependencies ! :-)
[]
*Vincent Massol
[[1]]common build structure
[[2]]build best practices enforcement (shared build meme)
[[3]]automated build of application, from source code to pre-production platform => fast time to market with reduced risks
[[4]]works well with distributed teams ;-) Location doesn't matter.
[]
Compared to Ant:
[[1]]Higher level of reusability between builds
[[2]]Faster turn around time to set up a powerful build (once you're used to Maven)
[[3]]Less maintenance
[[4]]Shared build meme. I know how to build any maven project
[[5]]Greater momentum: Ant is now legacy and not moving fast ahead. Maven is forging ahead fast and there's a potential of having lots of high-value
tools around Maven (CI, Dashboard project, IDE integration, etc).
[]
*Emmanuel Venisse
[[1]]All artifacts are versionned and store in a repository
[[2]]build process is standardized for all projects
[[3]]a lot of goals are available so it isn't necessary to develop some specific build process part contrary to ANT
we can reuse existing ANT tasks in build process with antrun plugin
[[4]]it provide quality project information with generated site
[[5]]Easy to learn and use
[]
*David Jackman
[[1]]Dependency management
[[2]]Makes the build process much easier at the project level (i.e. don't have to create very much for each project for Maven to build it
correctly, and those things you do create are more declarative than functional)
[[3]]Automatic project web sites with consistent information about each project
[[4]]Recommended standards and best practices for project layout and definition
[]
*Jesse Mcconnell
[[1]] Promotes modular design of code.
by making it simple to manage mulitple projects it allows the design to be laid out into muliple logical parts, weaving
these parts together through the use of dependency tracking in pom files.
[[2]] Enforces modular design of code.
it is easy to pay lipservice to modular code, but when the code is in seperate compiling projects it is impossible to
cross pollinate references between modules of code unless you specifically allow for it in your dependency management...
there is no 'I'll just do this now and fix it later' implementations.
[[3]] Dependency Management is clearly declared.
with the dependency management mechanism you have to try to screw up your jar versioning...there is none of the classic
problem of 'which version of this vendor jar is this?' And setting it up on an existing project rips the top off of
the existing mess if it exists when you are forced to make 'unknown' versions in your repository to get things up
and running...that or lie to yourself that you know the actual version of ABC.jar.
[[4]] strong typed life cycle
there is a strong defined lifecycle that a software system goes thru from the initiation of a build to the end...
and the users are allowed to mix and match their system to the lifecycle instead of cobble together their own
lifecycle.. this has the additional benefit of allowing people to move from one project to another and speak
using the same vocabulary in terms of software building
[]
*Henning
[[1]] quick project setup, no complicated build.xml files, just a POM and go
[[2]] all developers in a project use the same jar dependencies due to centralized POM.
[[3]] getting a number of reports and metrics for a project "for free"
[[4]] reduce the size of source distributions, because jars can be pulled from a central location
*Roberto Castro
[[1]] Consistency in artifact naming
[[2]] Use of remote repository
[[3]] Web site generation
[]

82
maven-site/src/site/apt/documentation-required.apt
View File

@ -1,82 +0,0 @@
-----
Documentation Required
-----
Jason van Zyl
-----
12 October 2005
-----
Documentation Required
This page lists some of the most pressing documentation needs. If you feel something is missing, please be sure
to let us know at the {{{/mail-lists.html}>Maven Users Mailing List}}.
* Documentation for users
* New SNAPSHOT handling
* Guide to dependencies, including:
* Dependency scoping - <especially system scope>
* Version range specifications
* Conflict resolution>
* Deployment mechanism
* Dependency management
* Plugin management - <in progress by J Matthew Pryor and John Casey>
* Plugin configuration
* Plugin downloading
* Report generation
* Project inheritence and company wide strategy
* Plugin documentation
* Using POM-properties in conjunction with plugin configuration to abstract child-POM configs
* Archetypes - writing and using
* Plugin usage guide/summary for core plugins - <esp. release plugin</i>
* Strategy for migrating from Ant builds
* Strategy for migrating from Maven 1.x builds - <esp. plugins that don't convert directly>
[]
* Documentation for plugin authors
* Beanshell examples
* Plugin writing guide
* Report writing guide
* Site customisation guide
* Common tips and tricks for accessing project/build data
* Guide to available parameter expressions
* List of standards for submitting new plugins (minimum documentation, test coverage?)
[]
* Documentation for Maven developers
* Lifecycle architecture</li>
* High level architecture, components explanation</li>
* Intro to Plexus</li>
* Contributors guide (add to current and consolidate, walk through some first steps)
[]

75
maven-site/src/site/apt/download.apt
View File

@ -1,75 +0,0 @@
------
Download Maven 2.0
------
Brett Porter
------
4 October 2005
------
Download Maven 2.0
Maven is distributed in several formats for your convenience.
You will be prompted for a mirror - if the file is not found on yours, please be patient, as it may take 24
hours to reach all mirrors.
Maven 2.0 is distributed under the {{{http://maven.apache.org/license.html} Apache License, version 2.0}}.
Also available is a distribution suitable for use with Ant to use Maven 2.0's dependency
management (including transitive dependencies), repository and artifact deployment support.
See {{{ant-tasks.html} Ant Tasks}} for more information and installation instructions.
*-------------------------+---------+----------+-----------+
| | Mirrors | Checksum | Signature |
*-------------------------+---------+----------+-----------+
| Maven 2.0 (tar.bz2) | {{{http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-2.0-bin.tar.bz2?update=200510191232} maven-2.0-bin.tar.bz2}} | {{{http://www.apache.org/dist/maven/binaries/maven-2.0-bin.tar.bz2.md5} maven-2.0-bin.tar.bz2.md5}} | {{{http://www.apache.org/dist/maven/binaries/maven-2.0-bin.tar.bz2.asc} maven-2.0-bin.tar.bz2.asc}} |
*-------------------------+---------+----------+-----------+
| Maven 2.0 (tar.gz) | {{{http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-2.0-bin.tar.gz?update=200510191232} maven-2.0-bin.tar.gz}} | {{{http://www.apache.org/dist/maven/binaries/maven-2.0-bin.tar.gz.md5} maven-2.0-bin.tar.gz.md5}} | {{{http://www.apache.org/dist/maven/binaries/maven-2.0-bin.tar.gz.asc} maven-2.0-bin.tar.gz.asc}} |
*-------------------------+---------+----------+-----------+
| Maven 2.0 (zip) | {{{http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-2.0-bin.zip?update=200510191232} maven-2.0-bin.zip}} | {{{http://www.apache.org/dist/maven/binaries/maven-2.0-bin.zip.md5} maven-2.0-bin.zip.md5}} | {{{http://www.apache.org/dist/maven/binaries/maven-2.0-bin.zip.asc} maven-2.0-bin.zip.asc}} |
*-------------------------+---------+----------+-----------+
| Maven 2.0 Tasks for Ant | {{{http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-artifact-ant-2.0-dep.jar?update=200510191232} maven-artifact-ant-2.0-dep.jar}} | {{{http://www.apache.org/dist/maven/binaries/maven-artifact-ant-2.0-dep.jar.md5} maven-artifact-ant-2.0-dep.jar.md5}} | {{{http://www.apache.org/dist/maven/binaries/maven-artifact-ant-2.0-dep.jar.asc} maven-artifact-ant-2.0-dep.jar.asc}} |
*-------------------------+---------+----------+-----------+
* System {Requirements}
*----------------------+---------------------------------------------------------------------------------------------+
| <<JDK>> | 1.4 or above (this is to execute Maven - it still allows you to build against 1.3 and prior JDK's)
*----------------------+---------------------------------------------------------------------------------------------+
| <<Memory>> | No minimum requirement
*----------------------+---------------------------------------------------------------------------------------------+
| <<Disk>> | No minimum requirement. Approximately 100MB will be used for your local repository, however this will vary depending on usage and can be removed and redownloaded at any time.
*----------------------+---------------------------------------------------------------------------------------------+
| <<Operating System>> | No minimum requirement. On Windows, Windows NT and above or Cygwin is required for the startup scripts. Tested on Windows XP, Fedora Core and Mac OS X.
*----------------------+---------------------------------------------------------------------------------------------+
* {Installation} Instructions
** Windows 2000/XP
[[1]] Unzip <<<maven-2.0-bin.zip>>> to the directory you wish to install Maven 2.0. These instructions
assume you chose <<<C:\Program Files\Apache Software Foundation\maven-2.0>>>
[[2]] Add the <<<bin>>> directory to your path, by opening up the system properties (WinKey + Pause),
selecting the "Advanced" tab, and the "Environment Variables" button, then editing the <<<PATH>>>
variable in the user variables. eg.
<<<"C:\Program Files\Apache Software Foundation\maven-2.0\bin";%PATH%>>>
[[3]] In the same dialog, make sure that <<<JAVA_HOME>>> is set to the location of your JDK,
eg. <<<C:\Program Files\Java\jdk1.5.0_02>>>
[[4]] Run <<<mvn --version>>> to verify that it is correctly installed.
** Unix-based Operating Systems (Linux, Solaris and Mac OS X)
[[1]] Extract the distribution archive to the directory you wish to install Maven 2.0. These instructions
assume you chose <<</usr/local/maven-2.0>>>. The directory <<<maven-2.0>>> will be created from
the archive.
[[2]] Add the <<<bin>>> directory to your path, eg. <<<export PATH=/usr/local/maven-2.0/bin:$PATH>>>
[[3]] Make sure that <<<JAVA_HOME>>> is set to the location of your JDK, eg.
<<<export JAVA_HOME=/usr/java/jdk1.5.0_02>>>
[[4]] Run <<<mvn --version>>> to verify that it is correctly installed.

79
maven-site/src/site/apt/glossary.apt
View File

@ -1,79 +0,0 @@
----
Maven Getting Started Guide
-----
Jason van Zyl
-----
12 October 2005
-----
Glossary
This document describes some of the most common terms encountered while using Maven. These terms, that have an
explicit meaning for Maven, can sometimes be confusing for newcomers.
* {<<Project>>}:
Maven thinks in terms of projects. Everything that you will build are projects. Those projects follow a well
defined "Project Object Model". Projects can depend on other projects, in which case the latter are called
"dependencies". A project may consistent of several subprojects, however these subprojects are
still treated equally as projects.
* {<<Project Object Model (POM)>>}:
The Project Object Model, almost always referred as the POM for brevity, is the metadata that Maven needs
to work with your project. Its name is "project.xml" and it is located in the root directory of each project.
* {<<Artifact>>}:
An artifact is something that is either produced or used by a project. Examples of artifacts produced by Maven for a project
include: JARs, source and binary distributions, WARs. Each artifact is uniquely identified by a {{{GroupId}group id}}
and an artifact ID which is unique within a group.
* {<<GroupId>>}:
A group ID is a universally unique identifier for a project. While this is often just
the project name (eg. <<<commons-collections>>>), it is helpful to use a fully-qualified
package name to distinguish it from other projects with a similar name (eg. <<<org.apache.maven>>>).
* {<<Dependency>>}:
A typical Java project relies on libraries to build and/or run.
Those are called "dependencies" inside Maven. Those dependencies are
usually other projects' JAR artifacts, but are referenced by the POM
that describes them.
* {<<Plug-in>>}:
Maven is organized in plugins. Every piece of functionality in Maven is provided by a plugin.
Plugins provide {{{Goal}goals}} and use the metadata found in the POM to perform their task.
Examples of plugins are: jar, eclipse, war. Plugins are primarily written in Java, but Maven
also supports writing plug-ins in Beanshell and Ant Scripting.
~~ * {<<Goal>>}: and phases
~~ Goals are what are executed to perform an action on the project. For example, the
~~ <<<jar:jar>>> will compile the current project and produce a JAR.
~~ Each goal exists in a plugin (except for those that you define yourself), and the
~~ goal name usually reflects the plugin (eg. <<<java:compile>>> comes from the
~~ <<<java>>> plugin).
* {<<Repository>>}:
Refer to {{{guides/introduction/introduction-to-repositories.html}Introduction to Repositories}}
* {<<Snapshots>>}:
Projects can (and should) have a special version including <<<SNAPSHOT>>>
to indicate that they are a "work in progress", and are not yet released. When a
snapshot dependency is encountered, it is always looked for in all remote repositories,
and downloaded again if newer than the local copy.
The version can either be the string <<<SNAPSHOT>>> itself, indicating
"the very latest" development version, or something like <<<1.1-SNAPSHOT>>>,
indicating development that will be released as 1.1 (i.e. newer than 1.0, but not yet 1.1).
* {<<APT>>}:
APT is a wiki-like format of documentation that Maven currently understands.
For information on how to create APT files, refer to the
{{{guides/mini/guide-site.html}Guide to creating a site}} document.
* {<<XDoc>>}:
XDoc is the format of documentation that Maven currently understands. It is quite simple, and
allows embedding XHTML within a simple layout that is transformed into a uniform site.
For information on how to create XDoc files, refer to the
{{{guides/mini/guide-site.html}Guide to creating a site}} document.

89
maven-site/src/site/apt/guides/development/guide-building-m2.apt
View File

@ -1,89 +0,0 @@
------
Guide to Building Maven 2.0
------
Brett Porter
------
12 June 2005
------
Building Maven 2.0
* Why would I want to build Maven 2.0?
Building Maven 2.0 yourself is for one of two reasons:
* to try out a bleeding edge feature or bugfix (issues can be found in
{{{http://jira.codehaus.org/browse/MNG} JIRA}}),
* to fix a problem you are having and submit a patch to the developers team.
Note, that you don't need to bootstrap Maven for day to day use, or to develop plugins. While we encourage getting
involved and fixing bugs that you find, for day to day use we recommend using the latest release.
* Checking out the sources
All of the source code for Maven 2.0 and its related libraries are in {{{http://subversion.tigris.org/} Subversion}}.
You can {{{http://svn.apache.org/viewcvs.cgi/maven/} browse the repository}}, or checkout specific modules directly.
To build Maven 2.0, you need the <<<components>>> module. To check that out, run the command:
-------------------
svn co https://svn.apache.org/repos/asf/maven/components/trunk maven-components
-------------------
The <<<maven-components>>> directory will contain the source code. Note that this contains all of the plugins and
the Ant tasks.
Other modules you might be interested in related to Maven development are:
* <<<wagon/trunk>>> - Maven Wagon, used by the artifact code and others for providing the transport layer to
get and put artifacts in a repository.
* <<<scm/trunk>>> - Maven SCM, a generic API to communicate with various different SCM providers, used by
Continuum and the release and SCM plugins.
* {{{http://svn.plexus.codehaus.org/plexus/} Plexus}} - the IoC container used by Maven.
* Building Maven
Once you have checked out the code, change into the <<<maven-components>>> directory that was created.
You may want to setup a different environment to install Maven to other than your normal installation of a
release, so set the <<<M2_HOME>>> environment variable accordingly, e.g.:
----
export M2_HOME=/usr/local/maven-2.0-SNAPSHOT
PATH=$M2_HOME/bin:$PATH
----
or
----
set M2_HOME=c:\maven-2.0-SNAPSHOT
set PATH=%M2_HOME%\bin;%PATH%
----
From this, run the <<<m2-bootstrap-all>>> command for your system:
----
sh m2-bootstrap-all.sh
----
or
----
m2-bootstrap-all.bat
----
First, the code will be built, then using the new installation the plugins will be rebuilt and installed in the
local repository. Finally, a set of integration tests will run.
Note that it isn't necessary to have a previous version (alpha-X...) of maven 2 installed before bootstrap.
For bootstrap (exclusive possibility):
* M2_HOME is set to a directory that doesn't exist (if it exists, remove it)!
* M2_HOME directory contains a valid installation of m2 (ie $M2_HOME/bin/m2.conf or %M2_HOME%\bin\m2.conf exists).
If you have any problems or get any failures during the run, please report them to the
{{{/mail-lists.html} Maven Developers List}}.

70
maven-site/src/site/apt/guides/development/guide-helping.apt
View File

@ -1,70 +0,0 @@
------
Guide to helping with Maven
------
Brett Porter
Jason van Zyl
------
12 October 2005
------
Guide to helping with Maven
As with any open source project, there are several ways you can help:
* Join the {{{../../mail-lists.html}mailing list}} and answer other user's questions
* Report bugs, feature requests and other issues in the {{{../issue-tracking.html}issue tracking}} application.
* {{{guide-m2-development.html#Creating and submitting a patch}Submit patches}} to reported issues (both those you find, or that others have filed)
[]
Your participation in the community is much appreciated!
Why Would I Want to Help?
There are several reasons these are good things.
* By answering other people's questions, you can learn more for yourself</li>
* By submitting your own fixes, they get incorporated faster</li>
* By reporting issues, you ensure that bugs don't get missed, or forgotten</li>
* You are giving back to a community that has given you software for free</li>
How do I Join the Project?
Projects at Apache operate under a meritocracy, meaning those that the developers notice participating to a
high extent will be invited to join the project as a committer.
This is as much based on personality and ability to work with other developers and the community as it is with
proven technical ability. Being unhelpful to other users, or obviously looking to become a committer for bragging
rights and nothing else is frowned upon, as is asking to be made a committer without having contributed
sufficiently to be invited.
Developers Conventions
There are a number of conventions used in the project, which contributors and developers alike should follow for
consistency's sake.
* {{{guide-m2-development.html#Maven Code Style} Code Style}}
* {{{guide-m2-development.html#Commit Message Template} Commit Message Template}}
Resources for committers
* {{{http://www.apache.org/dev/} Developer Resources}}
* {{{http://www.apache.org/foundation/} About the Apache Software Foundation}}
* {{{http://www.apache.org/dev/committers.html} Committer FAQ}}
* {{{http://people.apache.org/~vgritsenko/stats/projects/maven.html} Web Stats}}
* {{{http://people.apache.org/~coar/mlists.html#maven.apache.org} Mailing List Stats}}
* {{{http://wiki.apache.org} Apache Wiki}}

244
maven-site/src/site/apt/guides/development/guide-m2-development.apt
View File

@ -1,244 +0,0 @@
------
Guide to Developing Maven
------
Emmanuel Venisse
Trygve Laugstol
------
8 July 2005
------
~~ Copyright 2005 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.
Developing Maven 2
This document describes how to get started into developing Maven 2 itself. There is a separate page describing how
to {{{building.html}building Maven 2}}.
* Finding some work to do
First of all you need something to work on! Unless you have found a particular issue you would like to work on
the Maven team has categorized a few issues that we could use <your> help to solve them. The list is on our
{{{http://docs.codehaus.org/display/MAVEN/How+to+help}Conflucene wiki}} and will be updated every 60 minutes.
JIRA also has RSS feeds available if you'd like to include those in your favorite feed aggregator.
We categorize the issues in three different categories:
* <<Noice>>: No previous exposure to the code needed.
<({{{http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=10500&resolutionIds=-1&customfield_10010=Novice&sorter/field=priority&sorter/order=ASC&sorter/field=issuekey&sorter/order=ASC&tempMax=25&reset=true&decorator=none}rss feed}})>
* <<Intermediate>>: Exposure to Maven pluins and/or internals required.
<({{{http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=10500&resolutionIds=-1&customfield_10010=Intermediate&sorter/field=priority&sorter/order=ASC&sorter/field=issuekey&sorter/order=ASC&tempMax=25&reset=true&decorator=none}rss feed}})>
* <<Expert>>: Good knowledge of Maven internals and it's dependencies required.
<({{{http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=10500&resolutionIds=-1&customfield_10010=Expert&sorter/field=priority&sorter/order=ASC&sorter/field=issuekey&sorter/order=ASC&tempMax=25&reset=true&decorator=none}rss feed}})>
[]
When you find a issue you would like to work on add a comment in the issue log so the core developers and other
people looking for work know that someone is already working on it.
* {Creating and submitting a patch}
When you have either completed an issue or just want some feedback on the work you have done, create a patch
and attach the patch to the issue in question. We have a couple of guidelines when creating patches:
* Always create the patch from the root of the maven project, i.e. where the pom.xml file is.
* Name the file <<<MNG-<issue number>-<artifact id>.patch>>>.
* When adding the patch add a comment to the JIRA suggesting the commit message. For information on what to include
in a commit message please take a look at the existing commit messages. Currently the commit mails are sent to
{{{http://mail-archives.apache.org/mod_mbox/maven-dev/}dev@maven.apache.org}} with the subject prefix "svn commit".
[]
An example on how to create a patch from the command line:
---
$ svn diff > MNG-123-maven-core.patch
---
If you are picking up an issue with a existing patch attached to the issue you can apply the patch to your working
directory directly from JIRA like this. The <<<wget>>> and <<<patch>>> commands will only be available if you are
on a UNIX platform or using Cygwin on windows.
---
$ wget -O - -q <URL to the patch from JIRA> | patch -p0
---
If the patch is in a local file <<<MNG-123.patch>>> and you want to apply that use this command:
---
$ patch -p0 < MNG-123.patch
---
A couple of notes:
* If you are using another tool for creating patches, make sure that the patch doesn't include absolute paths.
Including absolute paths in the patch will make the useless for us as we most likely don't have the same directory
structure as you.
* Make sure that you follow our code style.
* Other useful Subversion commands while developing
If you've done a chunk of work and you would like ditch your changes and start from scratch use this command to
revert to the original checkout:
---
$ svn revert -R .
---
The <<<-R>>> argument means that the command will recurse down all directories and revert all changes.
Before committing code to the Subversion repository we always set the <<<svn:ignore>>> property on the directory
to prevent some files and directories to be checked in. We always exclude the IDE project files and the <<<target/>>>
directory. Instead of keeping all of the excludes in mind all the time it's useful to put them all in a file and
reference the file with the <<<-F>>> option:
---
$ svn propset . svn:ignore -F ~/bin/svnignore
---
An example svnignore file:
---
target
*~
*.log
.classpath
.project
*.ipr
*.iws
*.iml
---
* Related Projects
Maven 2 has a few dependencies on other projects.
* Plexus
Plexus is a full-fledged container supporting different kinds of component lifecycles. It's native lifecycle
is like any other modern IoC container, using field injection of both requirements and configuration. All
core Maven 2 functionality are Plexus components.
You can read more about Plexus {{{http://plexus.codehaus.org}here}}.
* Modello
Modello is a simple tool for representing an object model and generate code and resources from the model. Maven is
using Modello to generate all Java objects, XML readers and writers, XML Schema and HTML documentation.
You can read more about Modello {{{http://modello.codehaus.org}here}}.
* Surefire
Surefire is a testing framework. It can run regular JUnit tests so you won't have to change anything in your code to
use it. It support scriping tests in BeanShell and Jython and has special "batteries" for writing acceptance and
functional tests for the web and for testing XML-RPC code.
You can read more about Surefire {{{http://surefire.codehaus.org}here}}.
* Doxia
Doxia is Maven's documentation engine. It has a sink and parser API that can be used to plug in support for input
and output documents. Currently it has support for these document formats:
*---------------------------+----+-----*
| Format | In | Out |
*---------------------------+----+-----*
| APT - Almost Plain Text | Y | N |
*---------------------------+----+-----*
| DocBook | Y | Y |
*---------------------------+----+-----*
| FML - FAQ Markup Language | Y | N/A |
*---------------------------+----+-----*
| LaTeX | N | Y |
*---------------------------+----+-----*
| RTF | N | Y |
*---------------------------+----+-----*
| XDoc | Y | Y |
*---------------------------+----+-----*
| XHTML | Y | Y |
*---------------------------+----+-----*
Available formats
You can read more about Doxia {{{http://doxia.codehaus.org}here}}.
* Mojo
"Mojo" is really two things when it comes to Maven. It is both Maven's plug-in API but also a separate Codehaus
project hosting these plugins.
{{{http://mojo.codehaus.org}The Mojo Project}} is a plugin forge for all non-core Maven plugins. As we try to keep
the Mojos as independent of Maven as possible to increase their reuse we try to keep them a bit away from Maven
itself. There is also a lower bar for becoming a part of the project.
* Sub Projects
** Maven SCM
Maven SCM (Source Control Management) is an reusable API which is independent of Maven itself and it is used by the
SCM related Maven Plugins. The core part of Maven itself doesn't depend on Maven SCM.
** Maven Wagon
Maven Wagon is also a standalone API that deals with transporting files and directories. Maven Core uses the Wagon
API to download and upload artifacts and artifact metadata and the site plug-in uses it to publish the site.
* Subversion Configuration
Before committing files in subversion repository, you need to read the
{{{http://www.apache.org/dev/version-control.html#https-svn}Committer Subversion Access}}
document and you must set your svn client with these properties file : {{svn-eol-style.txt}}
* {Maven Code Style}
The following sections show how to set up the code style for Maven in IDEA and Eclipse.
It is strongly preferred that patches use this style before they are spplied.
** IntelliJ IDEA 4.5+
Download <<<{{{../../maven-codestyle.xml}maven-codestyle.xml}}>>> and copy it to
<<<~/.IntelliJIDEA/config/codestyles>>> then restart IDEA. On Windows, try
<<<C:\Documents and Settings\<username>\.IntelliJIDEA\config\codestyles>>>
After this, restart IDEA and open the settings to select the new code style.
** Eclipse 3.x
Download <<<{{{../../maven-eclipse-codestyle.xml}maven-eclipse-codestyle.xml}}>>>.
After this, select Window \> Preferences, and open up the configuration for Java \> Code
Style \> Code Formatter. Click on the button labeled Import... and select the file you
downloaded. Give the style a name, and click OK.
* {Commit Message Template}
Commits should have a message that follows this template:
-----
PR: issue1, issue2 (using issue keys from JIRA, not URLs)
Submitted by: (when it was a patch, put that persons name there)
<< comment >>
-----
<<PR>> can be omitted if there was no relevant JIRA issue, though it is strongly encouraged to create one for significant
changes.
<<Submitted by>> only needs to be specified when a patch is being applied for a non-committer.

1251
maven-site/src/site/apt/guides/getting-started/index.apt
View File

File diff suppressed because it is too large Load Diff

141
maven-site/src/site/apt/guides/index.apt
View File

@ -1,141 +0,0 @@
------
Summary of Maven 2.x documentation
------
Jason van Zyl
------
12 October 2005
------
Documentation
* Getting Started Guide
* {{{getting-started/index.html}Getting Started Guide}}
* Mini Guides
* {{{mini/guide-apt-format.html}Guide to the APT Format}}
* {{{mini/guide-assemblies.html}Guide to Creating Assemblies}}
* {{{mini/guide-attached-tests.html}Guide to using attached tests}}
* {{{mini/guide-bash-m2-completion.html}Guide to Maven 2.x auto completion using BASH}}
* {{{mini/guide-configuring-plugins.html}Guide to Configuring Plug-ins}}
* {{{mini/guide-coping-with-sun-jars.html}Guide to Coping with Sun JARs}}
* {{{mini/guide-creating-archetypes.html}Guide to Creating Archetypes}}
* {{{mini/guide-deploy-ftp.html}Guide to deploying with FTP}}
* {{{mini/guide-deployment-security-settings.html}Guide to Deployment and Security Settings}}
* {{{mini/guide-deploy-ssh-external.html}Guide to deploying with an external SSH command}}
* {{{mini/guide-ear.html}Guide to EARs}}
* {{{mini/guide-embedding-m2.html}Guide to Embedding Maven 2.x}}
* {{{mini/guide-generating-sources.html}Guide to generating Sources}}
* {{{mini/guide-naming-conventions.html}Guide to naming conventions (groupId, artifactId, version)}}
* {{{mini/guide-ibiblio-upload.html}Guide to uploading artifacts to Ibiblio}}
* {{{mini/guide-maven-evangelism.html}Guide to maven evangelism, improving metadata in ibiblio}}
* {{{mini/guide-ide-eclipse.html}Guide to using Eclipse with Maven 2.x}}
* {{{mini/guide-ide-idea.html}Guide to using IDEA with Maven 2.x}}
* {{{mini/guide-ide-netbeans/guide-ide-netbeans.html}Guide to Using maven 2 in Netbeans 4.0 (4.1 and 5.0)}}
* {{{mini/guide-installing-3rd-party-jars.html}Guide to installing 3rd party JARs}}
* {{{mini/guide-m1-m2.html}Guide to Moving From Maven 1.x to Maven 2.x}}
* {{{mini/guide-manifest.html}Guide to Working with Manifests}}
* {{{mini/guide-maven-classloading.html}Guide to Maven Classloading}}
* {{{mini/guide-mirror-settings.html}Guide to Mirror Settings}}
* {{{mini/guide-multi-module.html}Guide to creating a multi-module build}}
* {{{mini/guide-multiple-repositories.html}Guide to using Multiple Repositories}}
* {{{mini/guide-proxies.html}Guide to using proxies}}
* {{{mini/guide-releasing.html}Guide to Releasing}}
* {{{mini/guide-site.html}Guide to creating a site}}
* {{{mini/guide-using-ant.html}Guide to using Ant with Maven}}
* {{{mini/guide-using-extensions.html}Guide to using Extensions}}
* {{{mini/guide-using-m1-repos-with-m2.html}Guide to using Maven 1.x repositories with Maven 2.x}}
* {{{mini/guide-using-modello.html}Guide to using Modello}}
* {{{mini/guide-webapp.html}Guide to Webapps}}
* Introductory Material
* {{{introduction/introduction-to-archetypes.html}Introduction to Archetypes}}
* {{{introduction/introduction-to-artifact-resolution.html}Introduction to repository definitions and artifact resolution}}
* {{{introduction/introduction-to-dependency-management.html}Introduction to dependency management}}
* {{{introduction/introduction-to-plugin-prefix-mapping.html}Introduction to Plugin Prefix Resolution}}
* {{{introduction/introduction-to-plugin-registry.html}Introduction to the Plugin Registry}}
* {{{introduction/introduction-to-plugins.html}Introduction to Maven 2.0 Plugin Development}}
* {{{introduction/introduction-to-profiles.html}Introduction to build profiles}}
* {{{introduction/introduction-to-repositories.html}Introduction to Repositories}}
* {{{introduction/introduction-to-the-lifecycle.html}Introduction to the Build Lifecycle}}
* {{{introduction/introduction-to-the-pom.html}Introduction to the POM}}
* {{{introduction/introduction-to-the-standard-directory-layout.html}Introduction to the Standard Directory Layout}}
* Plugin Guides
* {{{plugin/guide-java-plugin-development.html}Guide to Developing Java Plugins}}
* Development Guides
* {{{development/guide-building-m2.html}Guide to Building Maven 2.0}}
* {{{development/guide-helping.html}Guide to helping with Maven}}
* {{{development/guide-m2-development.html}Guide to Developing Maven}}
* Reference
* {{{../maven-model/maven.html}Project Descriptor}}
* {{{../maven-settings/settings.html}Settings Descriptor}}
* {{{../plugins/index.html}Available Plug-ins}}
* {{{../developers/mojo-api-specification.html}Mojo API}}
* {{{../ant-tasks.html}Ant Tasks}}
* {{{../glossary.html}Glossary}}
* {{{../maven-conventions.html}Maven Conventions}}
[]

40
maven-site/src/site/apt/guides/introduction/introduction-to-archetypes.apt
View File

@ -1,40 +0,0 @@
------
Introduction to Archetypes
------
Jason van Zyl
------
12 October 2005
------
Introduction to Archetypes
What is Archetype?
In short, Archetype is a Maven project templating toolkit. An archetype is defined as <an original pattern or model
from which all other things of the same kind are made>. The names fits as we are trying to provide a system that
provides a consistent means of generating Maven projects. Archetype will help authors create
Maven project templates for users, and provides users with the means to generate parameterized versions
of those project templates.
Using archetypes provides a great way to enable developers quickly in a way consistent with best practices employed
by your project or organization. Within the Maven project we use archetypes to try and get our users up and running
as quickly as possible by providing a sample project that demonstrates many of the features of Maven while introducing
new users to the best practices employed by Maven. In a matter of seconds a new user can have a working Maven project
to use a jumping board for investigating more of the features in Maven. We have also tried to make the Archetype
mechanism additive and by that we mean allowing portions of a project to captured in an archetype so that pieces
or aspects of a project can be added to existing projects. A good example of this is the Maven site archetype.
If, for example, you have used the quick start archetype to generate a working project you can then quickly
create a site for that project by using the site archetype within that existing project. You can do anything like
this with archetypes.
You may want to standardize J2EE development within your organization so you may want to provide archetypes
for EJBs, or WARs, or for your web services. Once these archetypes are created and deployed in your organizations
repository they are available for use by all developers within your organization.
* What makes up an Archetype?
Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of
archetype and a set of {{{http://jakarta.apache.org/velocity}Velocity}} templates which make up the prototype
project. If you would like to know how to make your archetypes please refer to our
{{{../mini/guide-creating-archetypes.html}Guide to creating archetypes}}.

52
maven-site/src/site/apt/guides/introduction/introduction-to-artifact-resolution.apt
View File

@ -1,52 +0,0 @@
---
Introduction to repository definitions and artifact resolution
---
John Casey
---
23-August-2005
---
Introduction to Repository definitions and artifact resolution
As you no doubt know by now, artifacts are a central concept to Maven. Since
artifacts are referenced in abstract terms (groupId/artifactId rather than
file path), they must be available in the Maven repository system in order
for the build process to resolve them. This really amounts to putting the
referenced artifacts into a Maven repository.
To promote flexibility in the configuration of your build environment,
Maven allows multiple repositories to be defined from which artifacts can
be resolved. Repositories are always defined in the POM, but since POMs can
inherit from one another, and POM dependencies are resolved transitively,
predicting which repository will be used to resolve a particular artifact
can be daunting.
This document will attempt to explain the rules involved with constructing
repository lists for resolving artifacts referenced in various parts of the
build process, and eliminate - or at least, reduce - the potential for
confusion when it comes to artifact resolution.
*Goals
The artifact resolution process in Maven has a couple of central goals which
should help make the build process as flexible and powerful as possible. They
are:
* Allow the local POM (the one being built) to have the first opportunity to
control resolution.
<NOTE: In the case of an inheritance hierarchy, the ancestor POMs are
appended to the current repository list in inside-out order.>
* Allow the declaring-POM (the one declaring the dependency, in the case of
transitivity) the second opportunity.
* Default to the repositories defined in the super-POM for resolution.
~~Repository list construction (for resolution)
~~~~Repository sources (local vs. default vs. inheritance vs. transitive POMs)
~~~~Preserving the authority of the POM which declares the artifacts
~~~~Local-wins priority (during inheritance AND transitive dependency resolution)
~~~~Keeping the super-POM repositories last in line (ensuring their default status)
~~The net effect: a sample walkthrough

97
maven-site/src/site/apt/guides/introduction/introduction-to-dependency-management.apt
View File

@ -1,97 +0,0 @@
------
Introduction to dependency management
------
Jason van Zyl
------
12 October 2005
------
Introduction to dependency management
Dependency management is one of the features of Maven that is best know to users and is one of the areas where
Maven excels. There is not much difficulty in managing dependencies for a single a project, but when you start
getting into dealing with multi-module projects and applications that consist of tens or hundreds of modules this
is where Maven can help you a great deal in maintaining a high degree of control and stability.
* How to maintain versions of dependencies in a multi-module
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Application</name>
<url>http://app.mycompany.com</url>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<!-- Will the scope be inherited? -->
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
+----+
+----+
<project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>app</artifactId>
<!-- how to manage this version -->
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>app-module-foo</artifactId>
<packaging>jar</packaging>
<!-- Is this inherited -->
<version>1.0-SNAPSHOT</version>
<name>Application Foo Module</name>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
</project>
+----+
+----+
<project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>app</artifactId>
<!-- how to manage this version -->
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>app-module-foo</artifactId>
<packaging>jar</packaging>
<!-- Is this inherited -->
<version>1.0-SNAPSHOT</version>
<name>Application Foo Module</name>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
</project>
+----+
~~ Exclusions in depMan and exclusions in child dep are not merged
~~ What other gotchas?

241
maven-site/src/site/apt/guides/introduction/introduction-to-dependency-mechanism.apt.txt
View File

@ -1,241 +0,0 @@
------
Introduction to the Dependency Mechanism
------
Brett Porter
Trygve Laugstol
------
12 October 2005
------
Introduction to the Dependency Mechanism
There are many aspects to working with dependencies in Maven. While it is not the sole focus of Maven, it
does comprise a large and important part of the system. Learn more about:
* Transitive Dependencies
* Dependency Scope
* Dependency Management
[]
<<NOTE:>> <This document is currently in the process of being written, so not all facets are covered.>
* Transitive Dependencies">
Transitive dependencies are a new feature in Maven 2.0. This allows you to avoid needing to discover and
specify the libraries that your own dependencies require, and including them automatically.
This feature is facilitated by reading the project files of your dependencies from the remote repositories
specified. In general, all dependencies of those projects are used in your project, as are any that the
project inherits from its parents, or from its dependencies, and so on.
There is no limit to the number of levels that dependencies can be gathered from, and will only cause a
problem if a cyclic dependency is discovered.
With transitive dependencies, the graph of included libraries can quickly grow quite large. For this reason,
there are some additional features that will limit which dependencies are included:
* <Dependency mediation>
- this determines what version of a dependency will be used when multiple
versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" - so
you can always guarantee a version by declaring it explicitly in your project's POM.
* <Dependency scope>
- this allows you to only include dependencies appropriate for the current stage
of the build. This is described in more detail below.
[]
* Dependency Scope
Dependency scope is used to limit the transitivity of a depedency, and also to affect the classpath used for
various build tasks.
There are 4 scopes available:
* <<compile>>
- this is the default scope, used if none is specified. Compile dependencies are available
in all classpaths.
* <<provided>>
- this is much like compile, but indicates you expect the JDK or a container to provide it.
It is only available on the compilation classpath, and is not transitive.
* <<runtime>>
- this scope indicates that the dependency is not required for compilation, but is for
execution. It is in the runtime and test classpaths, but not the compile classpath.
* <<test>>
- this scope indicates that the dependency is not required for normal use of the application, and
is only available for the test compilation and execution phases.
[]
Each of the scopes affects transitive dependencies in different ways, as is demonstrated in the table below.
If a dependency is set to the scope in the left column, dependencies with the scope across the top row will
result in a dependency in the main project with the scope listed at the intersection. If no scope is listed,
it means the dependency will be omitted.
*----------+------------+----------+----------+------+
| | compile | provided | runtime | test
*----------+------------+----------+----------+------+
| compile | compile(*) | - | runtime | -
*----------+------------+----------+----------+------+
| provided | provided | provided | provided | -
*----------+------------+----------+----------+------+
| runtime | runtime | - | runtime | _
*----------+------------+----------+----------+------+
| test | test | - | test | -
*----------+------------+----------+----------+------+
<<(*) Note:>>
it is intended that this should be runtime instead, so that all compile dependencies must
be explicitly listed - however, there is the case where the library you depend on extends a class from another
library, forcing you to have available at compile time. For this reason, compile time dependencies remain
as compile scope even when they are transitive.
* Dependency Management
The dependency management section is a mechanism for centralizing dependency information. When you have
a set of projects that inherits a common parent it's possible to put all information about the dependency
in the common POM and have simpler references to the artifacts in the child POMs. The mechanism is best
illustrated through some examples. Given these two POMs which extend the same parent:
Project A:
+----+
<project>
...
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>group-c</groupId>
<artifactId>excluded-artifact</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</project>
+----+
Project B:
+----+
<project>
...
<dependencies>
<dependency>
<groupId>group-c</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</project>
+----+
These two example POMs share a common dependency and each has one non-trivial dependency. This information
can be put in the parent POM like this:
+----+
<project>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>group-c</groupId>
<artifactId>excluded-artifact</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>group-c</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
+----+
And then the two child poms would become much simpler:
+----+
<project>
...
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
</dependency>
</dependencies>
</project>
+----+
+----+
<project>
...
<dependencies>
<dependency>
<groupId>group-c</groupId>
<artifactId>artifact-b</artifactId>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
</dependency>
</dependencies>
</project>
+----+
The reference information about the dependency management tags is available from the
{{{maven-model/maven.html#class_DependencyManagement}project descriptor reference}}.

107
maven-site/src/site/apt/guides/introduction/introduction-to-plugin-prefix-mapping.apt
View File

@ -1,107 +0,0 @@
---
Introduction to Plugin Prefix Resolution
---
John Casey
---
30-July-2005
---
Introduction to Plugin Prefix Resolution
When you execute Maven using a standard lifecycle phase, resolving the
plugins that participate in that lifecycle is a relatively simple process.
However, when you directly invoke a mojo from the command line, as in the case
of <<clean:clean>>, Maven must have some way of reliably resolving the
<<clean>> plugin prefix to the <<maven-clean-plugin>>. This provides brevity
for command-line invocations, while preserving the descriptiveness of the
plugin's real artifactId.
To complicate matters even more, not all plugins should be forced to have the
same groupId in the repository. Since groupIds are presumed to be controlled
by one project, and multiple projects may release plugins for Maven, it
follows that plugin-prefix mappings must also accommodate multiple plugin
groupIds.
To address these concerns, Maven provides a new piece of repository-level
metadata (not associated with any single artifact) for plugin groups, along
with a plugin mapping manager to organize multiple plugin groups and provide
search functionality.
* Mapping Prefixes to Plugins
Quite simply, for each group of plugins in the Maven repository
(distinguished by a common groupId), there exists a metadata file called
<<<plugins.xml>>>. This file consists of the <<groupId>> (for clarity when
the file is opened outside the context of the directory), and a group of
<<plugin>> elements. Each <<plugin>> in this list contains a <<prefix>>
element denoting the plugin's command-line prefix, and an <<artifactId>>
element, which provides the other side of the prefix mapping and provides
enough information to lookup and use the plugin. When a plugin is installed
or deployed, this metadata file is resolved and if necessary, the prefix
mapping for the plugin is updated. In the case of deployment, this metadata
file is persisted to the remote repository.
* Configuring Maven to Search for Plugins
By default, Maven will search the groupId <<org.apache.maven.plugins>>
for prefix-to-artifactId mappings for the plugins it needs to perform a given
build. However, as previously mentioned, the user may have a need for
third-party plugins. Since the Maven project is assumed to have control over
the default plugin groupId, this means configuring Maven to search other
groupId locations for plugin-prefix mappings.
As it turns out, this is simple. In the Maven settings file (per-user:
<<<~/.m2/settings.xml>>>; global: <<<$M2_HOME/conf/settings.xml>>>), you can
provide a custom <<pluginGroups>> section, listing the plugin groupIds you
want to search (each groupId goes in its own <<pluginGroup>> sub-element).
For example, if my project uses a Modello model file, I might have the
following in my settings:
+---+
<pluginGroups>
<pluginGroup>org.codehaus.modello</pluginGroup>
</pluginGroups>
+---+
This allows me to execute the following, which will generate Java classes
from the model:
+---+
mvn -Dversion=4.0.0 -Dmodel=maven.mdo modello:java
+---+
Adding <<org.codehaus.modello>> to the list of groupIds searched for plugin
prefixes will automatically import all of the modello maven plugins, but it
<<will not>> block the import of plugins from the <<org.apache.maven.plugins>>
group - this plugin groupId is always the default, and cannot be suppressed.
* Current Quirks
The following list of items are on the table to be listed as bugs, and fixed.
They currently amount to quirks in the prefix resolution process.
* The <<org.apache.maven.plugins>> groupId is only used if <<no other plugin
groupId can be found to match the given prefix>>. This means that I can
develop a third-party plugin that overloads the <<<compiler>>> prefix, which
will drastically change the build behavior. Prefixes already mapped to the
<<org.apache.maven.plugins>> groupId should <<NOT>> be overridden, IMO.
* <<<plugins.xml>>> metadata are resolved from the first repository possible,
rather than being merged. If two plugin repositories provide plugins in the
the same groupId, none but the plugins in the first repository can be
found using plugin-prefix resolution. IMO, this is by design and should not
change, particularly if we agree that a single project maintains control
over the groupId in question.
<<NOTE:>> One interesting side-effect of this is that snapshot-capable
repositories may have subtle interactions with "normal" repositories in this
respect (with one repository suppressing or being suppressed by the other,
but both serving the same project/groupId).
* If you are testing a new plugin, and perform an install, the <<<plugins.xml>>>
for that plugin groupId will only be modified locally. If, at the next build,
you reference a plugin prefix that is not mapped in the local copy of any
configured plugin-prefix metadata, these metadata files will be re-resolved
from the remote repositories. This refresh step will erase the prefix mapping
for the locally installed plugin, erasing your ability to reference it without
configuring it explicitly in your <<<pom.xml>>>.

191
maven-site/src/site/apt/guides/introduction/introduction-to-plugin-registry.apt
View File

@ -1,191 +0,0 @@
---
Introduction to the Plugin Registry
---
John Casey
---
29-July-2005
---
Introduction to the Plugin Registry
The Maven 2 plugin registry (~/.m2/plugin-registry.xml) is a mechanism to
help the user exert some control over their build environment. Rather than
simply fetching the latest version of every plugin used in a given build,
this registry allows the user to peg a plugin to a particular version, and
only update to newer versions under certain restricted circumstances. There
are various ways to configure or bypass this feature, and the feature itself
can be managed on either a per-user or global level.
* A Tour of plugin-registry.xml
The plugin registry file (per-user: ~/.m2/plugin-registry.xml, global:
$M2_HOME/conf/plugin-registry.xml) contains a set of plugin-version
registrations, along with some configuration parameters for the registry
itself.
Currently, the plugin registry supports configuration options for the
following:
* <<updateInterval>> - Determines how often (or whether) the registered
plugins are checked for updates.
Combined with the <<lastChecked>> plugin attribute, this determines whether
a particular plugin will be checked for updates during a given build. Valid
settings are: never, always, and interval:TTT (TTT is a short specification
for a time interval, which follows the pattern /([0-9]+[wdhm])+/). Intervals
are specified down to the minute resolution. An example of an interval
specification might be:
<<<interval:4w2h30m>>> (check every 4 weeks, 2 hours, and 30 minutes)
* <<autoUpdate>> - Specifies whether the user should be prompted before
registering plugin-version updates. This is a boolean value, accepting
true/false.
* <<checkLatest>> - Specifies whether the LATEST artifact metadata should
be consulted while determining versions for <unregistered> plugins.
LATEST metadata is always published when a plugin is installed or deployed
to a repository, and so will always reference the newest copy of the plugin,
regardless of whether this is a snapshot version or not.
<NOTE:> Registered plugins will currently only ever be updated with the
results of RELEASE metadata resolution.
Obviously, the plugin registry also contains information about resolved plugin
versions. The following information is tracked for each registered plugin:
* <<groupId>> - The plugin's group id.
* <<artifactId>> - The plugin's artifact id.
* <<lastChecked>> - The timestamp from the last time updates were checked for
this plugin.
* <<useVersion>> - The currently registered version for this plugin. This is
the version Maven will use when executing this plugin's mojos.
* <<rejectedVersions>> - A list of versions discovered for this plugin which
have been rejected by the user. This keeps Maven from continually prompting
the user to update a given plugin to the same new version.
* Using (or not) the Plugin Registry
There are many ways you can override the default plugin registry settings.
Often, this will be desirable for a single, one-off build of a project that
deviates from your normal environment configuration. However, before discussing
these options, it's important to understand how the plugin registry resolves
versions for unregistered plugins, along with plugins in need of an update
check.
** Resolving Plugin Versions
The plugin registry uses a relatively straightforward algorithm for resolving
plugin versions. However, considerations for when to check, when to prompt the
user, and when to persist resolved plugin versions complicate this
implementation considerably. In general, plugin versions are resolved using a
four-step process:
[[1]] Check for a plugin configuration in the MavenProject instance. Any
plugin configuration found in the MavenProject is treated as authoritative,
and will stop the plugin-version resolution/persistence process when
found.
[[2]] If the plugin registry is enabled, check it for an existing registered
version. If the plugin has been registered, a combination of the
updateInterval configuration and the lastChecked attribute (on the
plugin) determine whether the plugin needs to be checked for updates.
If the plugin doesn't need an update check, the registered version is
used.
If the plugin is due for an update check, the plugin-artifact's RELEASE
metadata is resolved. Resolution of this metadata may trigger a prompt
to notify the user of the new version, and/or persistence of the new
version in the registry. If the update is performed, the lastChecked
attribute is updated to reflect this.
[[3]] <If> the <<checkLatest>> configuration is set to <<<true>>>, or the
<<<'--check-plugin-latest'>>> CLI option (discussed later) is
provided, then the LATEST artifact metadata is resolved for the plugin.
If this metadata is resolved successfully, that version is used.
This may trigger a prompt to ask the user whether to register the
plugin, and a successive persistence step for the new plugin version.
[[4]] If the version still has not been resolved, RELEASE artifact
metadata is checked for the plugin. If this metadata resolves
successfully, it is the version used. This may also trigger a prompt
to ask the user whether to register the plugin, and a persistence step
registering the new plugin version.
I've alluded to prompting the user and persisting the plugin version into
the registry. Now, let's examine the circumstances under which these steps
actually take place.
There are two cases where the user may be prompted to change the plugin
registry; when the plugin is not registered, and when the plugin is registered,
but an updated version is discovered. By default, the user is prompted to save
the resolved version for each plugin, with the option of specifying that a
decision should be remembered and applied to all (either yes to all, or no
to all) plugins registry updates. However, it is also possible to bypass
this behavior in the following ways:
* Specify <<autoUpdate>> == <<<true>>> in the plugin-registry.xml. This
configuration parameter means that the user is not prompted, and all
updated/discovered versions are to be persisted.
* Specify <<<'--batch-mode'>>> (or <<<'-B'>>>) from the command line.
This functions in the same way as the <<autoUpdate>> config parameter
above.
* Specify <<<'--no-plugin-updates'>>> | <<<'-npu'>>> from the command line.
This prevents any updates or new registrations from taking place, but
existing plugin versions in the registry will be used when available.
* Specify <<<'--check-plugin-updates'>>> | <<<'--update-plugins'>>> |
<<<'-up'>>> | <<<'-cpu'>>> (synonyms) from the command line.
* Specify <<<'--no-plugin-registry'>>> | <<<'-npr'>>> from the command line.
This prevents resolution of plugin versions using the plugin-registry.xml
file. The plugin version will be resolved either from the project or
from the repository in this case.
* Specify <<usePluginRegistry>> == <<<false>>> in the settings.xml. This
configuration parameter will disable use of the plugin registry for the
entire build environment, as opposed to the immediate build execution
(as in the case of the corresponding command line switch above).
These force all registered plugins to be updated. The user will still
be prompted to approve plugin versions, unless one of the above switches
is also provided.
** Summary of Command Line Options for the Plugin Registry
The following summary of command line options is provided for quick reference:
* <<<--no-plugin-registry>>> - Bypass the plugin registry.
<Synonym:> <<<-npr>>>
* <<<--no-plugin-latest>>> - Don't check the LATEST artifact metadata when
resolving plugin versions, regardless of the value of <<useLatest>> in
the plugin-registry.xml file.
<Synonym:> <<<-npl>>>
* <<<--check-plugin-latest>>> - Check the LATEST artifact metadata when
resolving plugin versions, regardless of the value of <<useLatest>> in
the plugin-registry.xml file.
<Synonym:> <<<-cpl>>>
* <<<--no-plugin-updates>>> - Do not search for updated versions of registered
plugins. Only use the repository to resolve unregistered plugins.
<Synonym:> <<<-npu>>>
* <<<--check-plugin-updates>>> - Force the plugin version manager to check for
updated versions of any registered plugins, currently using RELEASE metadata
<<only>>.
<Synonyms:> <<<--update-plugins>>> <<<-up>>> <<<-cpu>>>

182
maven-site/src/site/apt/guides/introduction/introduction-to-plugins.apt
View File

@ -1,182 +0,0 @@
------
Introduction to Maven 2.0 Plugin Development
------
John Casey
------
24 June 2005
------
~~ 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.
Introduction to Maven 2.0 Plugin Development
Maven consists of a core engine which provides basic project-processing
capabilities and build-process management, and a host of plugins which are
used to execute the actual build tasks.
* What is a Plugin?
"Maven" is really just a core framework for a collection of
Maven Plugins. In other words, plugins are where much of the real action is
performed, plugins are used to: create jar files, create war files, compile
code, unit test code, create project documentation, and on and on. Almost
any action that you can think of performing on a project is implemented as
a Maven plugin.
Plugins are the central feature of Maven that allow for the reuse of
common build logic across multiple projects. They do this by executing an
"action" (i.e. creating a WAR file or compiling unit tests) in the context
of a project's description - the Project Object Model (POM). Plugin behavior
can be customized through a set of unique parameters which are exposed by a
description of each plugin goal (or Mojo).
One of the simplest plugins in Maven 2.0 is the Clean Plugin. The
{{{http://maven.apache.org/maven2/plugins/maven-clean-plugin/}Maven
Clean plugin}} (maven-clean-plugin) is responsible for removing the target
directory of a Maven 2 project. When you run "mvn clean:clean", Maven 2 executes
the "clean:clean" goal as defined in the Clean plug-in, and the target directory
is removed. The Clean plugin
{{{http://maven.apache.org/maven2/plugins/maven-clean-plugin/clean-mojo.html}defines
a parameter}} which can be used to customize plugin behavior, this parameter is
called outputDirectory and it defaults to ${project.build.directory}.
* What is a Mojo (<And Why the H--- is it Named 'Mojo'>)?
A Mojo is really just a goal in Maven 2, and plug-ins consist of
any number of goals (Mojos). Mojos can be defined as annotated Java classes or
Beanshell script. A Mojo specifies
metadata about a goal: a goal name, which phase of the lifecycle it fits into,
and the parameters it is expecting.
MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for
"Plain". Mojo is also an iteresting word (see {{{http://www.answers.com/mojo&r=67}definition}}).
From {{{http://www.wikipedia.org}Wikipedia}}, a "mojo" is defined as:
"...a small bag worn by a person under the clothes (also known as a mojo hand).
Such bags were thought to have supernatural powers, such as protecting from evil,
bringing good luck, etc."
* What is the Build Lifecycle? (Overview)
The build lifecycle is a series of common stages through which all project
builds naturally progress. Plugin goals are bound to specific stages in the
lifecycle.
Resources
[[1]] {{{../plugin/guide-java-plugin-development.html}Plugin development guide}}
[[2]] {{{../mini/guide-configuring-plugins.html}Configuring plugins}}
Comparison to Maven 1.x Plugins
* Similarities to Maven 1.x
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.
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.
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 architecture - at least to
our minds. <<;-)>>
* Differences from Maven 1.x
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.
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.
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.
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 <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.
* Why Change the Plugin Architecture?
See the previous section for the long version, but the short version can
be summed up by the following list of benefits.
* A managed lifecycle
* Multiple implementation languages
* Reusability outside of the build system
* The ability to write Maven plugins entirely in Java
In Maven 1.0, a plugin was defined using Jelly, and while it was possibly to
write a plugin in Java, you still had to wrap your plugin with some obligatory
Jelly script. An XML-based scripting language which is interpreted at run-time
isn't going to be the best choice for performance, and the development team
thought it wise to adopt an approach which would allow plugin developers to
choose from an array of plugin implementation choices. The first choice in
Maven 2 should be Java plugins, but you may also use one of the supported
scripting languages like Beanshell.
To summarize, the development team saw some critical gaps in the API and
architecture of Maven 1.0 plug-ins, and the team decided that addressing
these deficiencies was critical to the future progress of Maven from a useful
tool to something more robust.

368
maven-site/src/site/apt/guides/introduction/introduction-to-profiles.apt
View File

@ -1,368 +0,0 @@
---
Introduction to build profiles
---
30-July-2005
---
John Casey
---
Introduction to Build Profiles
Maven 2.0 goes to great lengths to ensure that builds are portable. Among
other things, this means allowing build configuration inside the POM,
avoiding <<all>> filesystem references (in inhertiance, dependencies, and
other places), and leaning much more heavily on the local repository to
store the metadata needed to make this possible.
However, sometimes portability is not entirely possible. Under certain
conditions, plugins may need to be configured with local filesystem paths.
Under other circumstances, a slightly different dependency set will be
required, and the project's artifact name may need to be adjusted slightly.
And at still other times, you may even need to include a whole plugin in the
build lifecycle depending on the detected build environment.
To address these circumstances, Maven 2.0 introduces the concept of a build
profile. Profiles are specified using a subset of the elements available in
the POM itself (plus one extra section), and are triggered in any of a
variety of ways. They modify the POM at build time, and are meant to be used
in complementary sets to give equivalent-but-different parameters for a set
of target environments (providing, for example, the path of the appserver root
in the development, testing, and production environments). As such, profiles
can easily lead to differing build results from different members of your team.
However, used properly, profiles can be used while still preserving
project portability.
* Profile Locations
Build profiles can be specified in any of three locations:
* the Maven settings file
* a file in the the project basedir called <<<profiles.xml>>>
* in the POM itself
As we'll discuss later, the location of the profile determines what parameters
of the POM it can modify.
* Triggering Profiles
Profile triggering also happens in one of three general ways:
* Profiles can be explicitly specified using the <<<-P>>> CLI option.
This option takes an argument that is a comma-delimited list of
profile-ids to be used. When this option is specified, no profiles other
than those specified in the option argument will be activated.
* Profiles can be activated in the Maven settings, via the <<activeProfiles>>
section. This section takes a list of <<activeProfile>> elements, each
containing a profile-id inside.
* Profiles can be automatically triggered based on the detected state of
the build environment. These triggers are specified via an <<activation>>
section in the profile itself. Currently, this detection is limited to
prefix-matching of the JDK version, the presence of a system property, or
the value of a system property. Here are some examples:
+---+
<activation>
<jdk>1.4</jdk>
</activation>
+---+
This will trigger the profile when the JDK's version starts with "1.4" (eg.
"1.4.0_08", "1.4.2_07", "1.4").
+---+
<activation>
<property>
<name>debug</name>
</property>
</activation>
+---+
This will activate the profile when the system property "debug" is specified
with any value.
+---+
<activation>
<property>
<name>environment</name>
<value>test</value>
</property>
</activation>
+---+
This last example will trigger the profile when the system property
"environment" is specified with the value "test".
* What Can I Configure in a Profile?
Now that we've talked about where to specify profiles, and how to activate them,
it will be useful to talk about <what> you can specify in a profile. As with
the other aspects of profile configuration, this answer is not straightforward.
Depending on where you choose to configure your profile, you will have access
to varying POM configuration options. Profiles specified in external files
(i.e in <<<settings.xml>>> or <<<profiles.xml>>>) are not portable in the
strictest sense, because they externalize some of the build configuration from
the only project metadata that is maintained on the remote repositories: the
POM. Therefore, you will only be able to modify the <<repositories>> and
<<pluginRepositories>> sections of the POM, plus an extra <<properties>>
section.
The <<properties>> section allows you to specify free-form key-value pairs
which will be included in the interpolation process for the POM. This allows
you to specify a plugin configuration in the form of $\{profile.provided.path\}.
On the other hand, if your profiles can be reasonably specified <inside> the
POM, you have many more options. The trade-off, of course, is that you can
only modify <that> project and it's sub-modules. Since these profiles are
specified inline, and therefore have a better chance of preserving portability,
it's reasonable to say you can add more information to them without the risk
of that information being unavailable to other users.
Profiles specified in the POM can modify the following POM elements:
* <<repositories>>
* <<pluginRepositories>>
* <<dependencies>>
* <<plugins>>
* <<properties>> (not actually available in the main POM, but used behind the
scenes)
* <<modules>>
* <<reporting>>
* <<dependencyManagement>>
* <<distributionManagement>>
* a subset of the <<build>> element, which consists of:
* <<defaultGoal>>
* <<resources>>
* <<testResources>>
* <<finalName>>
* Profile Pitfalls
We've already mentioned the fact that adding profiles to your build has the
potential to break portability for your project. We've even gone so far as to
highlight circumstances where profiles are likely to break project portability.
However, it's worth reiterating those points as part of a more coherent
discussion about some pitfalls to avoid when using profiles.
There are two main problem areas to keep in mind when using profiles.
First are external properties, usually used in plugin configurations. These pose
the risk of breaking portability in your project. The other, more subtle area
is the incomplete specification of a natural set of profiles.
** External Properties
External property definition concerns any property value defined outside
the <<<pom.xml>>> but not defined in a corresponding profile inside it.
The most obvious usage of properties in the POM is in plugin configuration.
While it is certainly possible to break project portability without properties,
these critters can have subtle effects that cause builds to fail. For example,
specifying appserver paths in a profile that is specified in the
<<<settings.xml>>> may cause your integration test plugin to fail when another
user on the team attempts to build without a similar <<<settings.xml>>>.
Consider the following <<<pom.xml>>> snippet for a web application project:
+---+
...
<build>
<plugins>
<plugin>
<groupId>org.myco.plugins</groupId>
<artifactId>spiffy-integrationTest-plugin</artifactId>
<version>1.0</version>
<configuration>
<appserverHome>$\{appserver.home\}</appserverHome>
</configuration>
</plugin>
</plugins>
</build>
...
+---+
Now, in your local <<<~/.m2/settings.xml>>>, you have:
+---+
<profiles>
<profile>
<id>appserverConfig</id>
<properties>
<appserver.home>/path/to/appserver</appserver.home>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>appserverConfig</activeProfile>
</activeProfiles>
+---+
When you build the <<integration-test>> lifecycle phase, your integration
tests pass, since the path you've provided allows the test plugin to install
and test this web application.
<However>, when your your colleague attempts to build to <<integration-test>>,
his build fails spectacularly, complaining that it cannot resolve the plugin
configuration parameter \<appserverHome\>, or worse, that the value of that
parameter - literally $\{appserver.home\} - is invalid (if it warns you at all).
Congratulations, your project is now non-portable. Inlining this profile with
your <<<pom.xml>>> can help alleviate this, with the obvious drawback that
each project hierarchy (allowing for the effects of inheritance) now have to
specify this information. Since Maven provides good support for project
inheritance, it's possible to stick this sort of configuration in the
<<pluginManagement>> section of a team-level POM or similar, and simply
inherit the paths.
Another, less attractive answer might be standardization of development
environments. However, this will tend to compromise the productivity
gain that Maven is capable of providing.
** Incomplete Specification of a Natural Profile Set
In addition to the above portability-breaker, it's easy to fail to cover all
cases with your profiles. When you do this, you're usually leaving one of
your target environments high and dry. Let's take the example <<<pom.xml>>>
snippet from above one more time:
+---+
...
<build>
<plugins>
<plugin>
<groupId>org.myco.plugins</groupId>
<artifactId>spiffy-integrationTest-plugin</artifactId>
<version>1.0</version>
<configuration>
<appserverHome>$\{appserver.home\}</appserverHome>
</configuration>
</plugin>
</plugins>
</build>
...
+---+
Now, consider the following profile, which would be specified inline with the
<<<pom.xml>>>:
+---+
<profiles>
<profile>
<id>appserverConfig-dev</id>
<activation>
<property>
<name>env</name>
<value>dev</value>
</property>
</activation>
<properties>
<appserver.home>/path/to/dev/appserver</appserver.home>
</properties>
</profile>
</profiles>
+---+
This profile looks quite similar to the one from last example, with a few
important exceptions: it's plainly geared toward a development environment,
and it has an activation section that will trigger its inclusion when the
system properties contain "env=dev". So, executing:
+---+
mvn -Denv=dev integration-test
+---+
should result in a successful build. However, this won't:
+---+
mvn -Denv=production integration-test
+---+
Why? Because, the resulting non-interpolated literal value of $\{appserver.home\}
will not be a valid path for deploying and testing your web application. We
haven't considered the case for the production environment when writing our
profiles. The "production" environment, along with "test" and possibly even
"local" constitute a natural set of target environments for which we may want
to build the integration-test lifecycle phase. The incomplete specification of
this natural set means we have effectively limited our valid target environments
to the development environment. Your teammates - and probably your manager -
will not see the humor in this. When you construct profiles to handle cases
such as these, be sure to address the entire set of target permutations.
As a quick aside, it's possible for user-specific profiles to act in a similar
way. This means that profiles for handling different environments which are
keyed to the user can act up when the team adds a new developer. While I
suppose this <could> act as useful training for the newbie, it's just wouldn't
be nice to throw them to the wolves in this way. Again, be sure to think of the
<whole> set of profiles.
* Naming Conventions
By now you've noticed that profiles are a natural way of addressing the problem of
different build configuration requirements for different target environments. Above,
we discussed the concept of a "natural set" of profiles to address this situation,
and the importance of considering the whole set of profiles that will be required.
However, the question of how to organize and manage the evolution of that set is
non-trivial as well. Just as a good developer strives to write self-documenting
code, it's important that your profile id's give a hint to their intended use.
One good way to do this is to use the common system property trigger as part of
the name for the profile. This might result in names like <<env-dev>>, <<env-test>>,
and <<env-prod>> for profiles that are triggered by the system property <<env>>.
Such a system leaves a highly intuitive hint on how to activate a build targeted
at a particular environment. Thus, to activate a build for the test environment,
you need to activate <<env-test>> by issuing:
+---+
mvn -Denv=test <phase>
+---+
The right command-line option can be had by simply substituting "=" for "-" in
the profile id.
* Getting Help
If you get lost when working with a profile-enabled build, you can get a glance
into the build-time POM and active profiles using the <<maven-projecthelp-plugin>>.
To see the list of active profiles, issue:
+---+
mvn projecthelp:active-profiles -Denv=test
+---+
This should render a bulleted list of the profiles (hopefully including one
named <<env-test>> for this build).
If you want to see the effect that the current active profiles have had on the
POM, issue:
+---+
mvn projecthelp:effective-pom -Denv=test
+---+
This will print the effective POM for this build configuration out to the
console. If you want to redirect it to a file called <<<effective-pom.xml>>>,
use the command-line option <<<-Doutput=effective-pom.xml>>>.

173
maven-site/src/site/apt/guides/introduction/introduction-to-repositories.apt
View File

@ -1,173 +0,0 @@
------
Introduction to Repositories
------
Jason van Zyl
------
12 October 2005
------
Introduction to Repositories
* Artifact Repositories
A repository in Maven is used to hold build artifacts and dependencies of varying types.
There are strictly only two types of repositories: local and remote. The local repository refers to a copy
on your own installation that is a cache of the remote downloads, and also contains the temporary
build artifacts that you have not yet released.
Remote repositories refer to any other type of repository, accessed by a variety of protocols such as
<<<file://>>> and <<<http://>>>. These repositories might be a truely remote repository
set up by a third party to provide their artifacts for downloading (for example,
<a href="http://www.ibiblio.org/maven/">Ibiblio</a> houses Maven's central repository).
Other "remote" repositories may be <a href="../reference/internal-repositories.html">internal repositories</a>
set up on a file or HTTP server within your company, used to share private artifacts between development teams
and for releases.
The local and remote repositories are structured the same way so that scripts can easily be run on either
side, or they can be synced for offline used. In general use, the layout of the repositories is completely
transparent to the Maven user, however.
* Why not Store JARs in CVS?
It is not recommended that you store your JARs in CVS. Maven tries to
promote the notion of a user local repository where JARs, or any
project artifacts, can be stored and used for any number of builds.
Many projects have dependencies such as XML parsers and standard utilities that
are often replicated in typical builds. With Maven these standard utilities
can be stored in your local repository and shared by any number of builds.
This has the following advantages:
* <<It uses less storage>> - while a repository is typically quite large, because each JAR is only kept
in the one place it is actually saving space, even though it may not seem that way</li>
* <<It makes checking out a project quicker>> - initial checkout, and to a small degree updating, a
project will be faster if there are no large binary files in CVS. While they may need to be downloaded
again afterwards anyway, this only happens once and may not be necessary for some common JARs already in
place.
* <<No need for versioning>> - CVS and other source control systems are designed for versioning files,
but external dependencies typically don't change, or if they do their filename changes anyway to indicate the
new version. Storing these in CVS doesn't have any added benefit over keeping them in a local artifact cache.
* Using Repositories
In general, you should not need to do anything with the local repository on a regular basis, except clean
it out if you are short on disk space (or erase it completely if you are willing to download everything again).
For the remote repositories, they are used for both downloading and uploading (if you have the permission to
do so).
** Downloading from a Remote Repository">
Downloading in Maven is triggered by a project declaring a dependency that is not present in the local
repository (or for a <<<SNAPSHOT>>>, when the remote repository contains one that is newer).
By default, Maven will download from Ibiblio.
To override this, you need to specify a <<<repositories>>> element as follows:
+----+
<project>
...
<repositories>
<repository>
<id></id>
<url></url>
</repository>
</repositories>
...
</project>
+----+
You can set this in your <code>~/build.properties</code> file to globally use a certain mirror, however
note that it is common for a project to customise the repository in their <code>project.properties</code>
and that your setting will take precedence. If you find that dependencies are not being found, check you
have not overridden the remote repository.
(Future versions should allow you to use a setting of
<<<${maven.repo.remote},http://planetmirror.com/maven>>>, but currently this causes an infinite recursion).
For more information on dependencies, see <a href="managing-dependencies.html">Handling Dependencies</a>.
* Building Offline
If you find you need to build your projects offline you can either use the offline switch on the CLI:
+---+
mvn -o package
+---+
Note that many plugins will honour the offline setting and not perform any operations that would connect to
the internet. Some examples are resolving Javadoc links and link checking the site.
* Uploading to a Remote Repository">
While this is possible for any type of remote repository, you must have the permission to do so.
To have someone upload to the central Maven repository, see {{../guide/guide-ibiblio-upload.html}Uploading to Ibiblio}}.
Internal Repositories
When using Maven, particularly in a corporate environment, connecting to the internet to download dependencies
is not acceptable for security, speed or bandwidth reasons. For that reason, it is desirable to set up an
internal repository to house a copy of artifacts, and to publish private artifacts to.
Such an internal repository can be downloaded from using HTTP or the file system (using a <code>file://</code>
URL), and uploaded to using SCP, FTP, or a file copy.
Note that as far as Maven is concerned, there is nothing special about this repository: it is another
<<remote repository>> that contains artifacts to download to a user's local cache, and is a publish
destination for artifact releases.
Additionally, you may want to share the repository server with your generated project sites. For more
information on creating and deploying sites, see <a href="../using/site.html">Creating a Site</a>.
* Setting up the Internal Repository
To set up an internal repository just requires that you have a place to put it, and then start copying
required artifacts there using the same layout as in a remote repository such as {{{http://www.ibiblio.org/maven/}Ibiblio}}.
It is <not> recommended that you scrape or <<<rsync://>>> a full copy of Ibiblio as there is a large amount
of data there. You can use a program such as <a href="http://maven-proxy.codehaus.org/">Maven Proxy</a>,
running on your internal repository's server, to download from the internet as required and then hold
the artifacts in your internal repository for faster downloading later.
The other options available are to manually download and vet releases, then copy them to the internal
repository, or to have Maven download them for a user, and manually upload the vetted artifacts to the
internal repository which is used for releases. This step is the only one available for artifacts where
the license forbids their distribution automatically, such as several J2EE JARs provided by Sun.
Refer to the {{{../mini/guide-coping-with-sun-jars.html}Guide to coping with SUN JARs}} document for more information.
It should be noted that Maven intends to include enhanced support for such features in the future,
including click through licenses on downloading, and verification of signatures.
* Using the Internal Repository
Using the internal repository is quite simple. Simply make a change to add a <<<repositories>>> element:
+----+
<project>
...
<repositories>
<repository>
<id></id>
<repository>
</repositories>
...
</project>
+----+
* Deploying to the Internal Repository
One of the most important reasons to have one or more internal repositories is to be able to publish
your own private releases to share.
To publish to the repository, you will need to have access via one of SCP, SFTP, FTP, or the filesystem.
For example, to set up an SCP transfer. ~~ show the scp example.

386
maven-site/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt
View File

@ -1,386 +0,0 @@
------
Introduction to the Build Lifecycle
------
Brett Porter
------
16 June 2005
------
Introduction to the Build Lifecycle
* Build Lifecycle Basics
Maven 2.0 is based around the central concept of a build lifecycle. What this means is that the process for building
and distributing a particular artifact is clearly defined.
For the person building a project, this means that it is only necessary to learn a small set of commands to build any
Maven project, and the POM will ensure they get the results they desired.
The most common lifecycle phases that would be executed on a project are the following (a complete list of the lifecycle phases is given below):
* <<<validate>>> - validate the project is correct and all necessary information is available
* <<<compile>>> - compile the source code of the project
* <<<test>>> - test the compiled source code using a suitable unit testing framework. These tests should not
require the code be packaged or deployed
* <<<package>>> - take the compiled code and package it in its distributable format, such as a JAR.
* <<<integration-test>>> - process and deploy the package if necessary into an environment where integration tests
can be run
* <<<verify>>> - run any checks to verify the package is valid and meets quality criteria
* <<<install>>> - install the package into the local repository, for use as a dependency in other projects locally
* <<<deploy>>> - done in an integration or release environment, copies the final package to the remote repository
for sharing with other developers and projects.
Note that for each of these steps, all previous steps are always executed, so you only need to specify the last one
you desire on the command line. For example:
-------
mvn install
-------
This command will compile, test, package, verify and install the package into the local repository when run.
There are more commands that are part of the lifecycle, which will be discussed in the following sections.
It should also be noted that the same command can be used in a multi-module scenario. For example;
------
mvn clean:clean install
------
This command will traverse into all of the subprojects and run <<<clean:clean>>>, then <<<install>>> (including all of
the prior steps).
* Setting up your Project to Use the Build Lifecycle
The build lifecycle is simple enough to use, but when you are constructing a Maven build for a project, how do you go
about assigning tasks to each of those build phases?
** Packaging
The first, and most common way, is to set the <<<packaging>>> for your project. This defaults to <<<jar>>>, so whether
you have specifically done it or not, this has already happened. Each packaging contains a list of goals to bind to
a particular phase. For example, a JAR will add the following bindings to the lifecycle:
*------------------------------+---------------------------------------------------------------------------------------+
| <<<process-resources>>> | <<<resources:resources>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<compile>>> | <<<compiler:compile>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<process-test-resources>>> | <<<resources:testResources>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<test-compile>>> | <<<compiler:testCompile>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<test>>> | <<<surefire:test>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<package>>> | <<<jar:jar>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<install>>> | <<<install:install>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<deploy>>> | <<<deploy:deploy>>>
*------------------------------+---------------------------------------------------------------------------------------+
This is an almost standard set of bindings; however, some packages handle them differently. For example, a project
that is purely metadata (packaging <<<pom>>>) only binds the <<<install>>> and <<<deploy>>> phases.
Note that for some packaging tpyes to be available, you may also need to include a particular plugin in your
<<<build>>> section (as described in the next section). One example of a plugin that requires this is the Plexus plugin,
which provides a <<<plexus-application>>> and <<<plexus-service>>> packaging.
** Plugins
The second way to add goals to phases is to configure plugins in your project. As you will see in the later sections,
plugins contain information that indicate which lifecycle phase to bind each goal to. Note that adding the plugin on its own is not
enough information - you must also specify the goals you want run as part of your build.
The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected.
If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed
first, followed by those configured in the POM. Note that you can use the <<<executions>>> element to gain more
control over the order of particular goals.
For example, the Modello plugin always binds <<<modello:java>>> to the <<<generate-sources>>> phase. So to use the
Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the
following to your POM in the <<<plugins>>> section of <<<build>>>:
----
...
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<executions>
<execution>
<configuration>
<model>maven.mdo</model>
<modelVersion>4.0.0</modelVersion>
</configuration>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
...
----
You might be wondering why that executions element is there. That is so that you can run the same goal multiple times
with different configuration if needed. Separate executions can also be given an ID so that during inheritence or the
application of profiles you can control whether goal configuration is merged or turned into an additional execution.
When multiple executions are given that match a particular phase, they are executed in the order specified in the POM,
with inherited executions running first.
Now, in the case of <<<modello:java>>>, it only makes sense in the <<<generate-sources>>> phase. But some goals can be
used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself.
For example, let's say you have a goal <<<touch:timestamp>>> that echos the current time to a file, and you want it to
run in the <<<process-test-resources>>> phase to indicate when the tests were started. This would be configured like
so:
----
...
<plugin>
<groupId>com.mycompany.example</groupId>
<artifactId>touch-maven-plugin</artifactId>
<executions>
<execution>
<phase>process-test-resources</phase>
<configuration>
<file>${project.output.directory}/timestamp.txt</file>
</configuration>
<goals>
<goal>timestamp</goal>
</goals>
</execution>
</executions>
</plugin>
...
----
* Build Lifecycle Phase Reference
The following lists all build lifecycle phases, which are executed in the order given up to the point of the one specified.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<validate>>> | validate the project is correct and all necessary information is available.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-sources>>> | generate any source code for inclusion in compilation.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-sources>>> | process the source code, for example to filter any values.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-resources>>> | generate resources for inclusion in the package.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-resources>>> | copy and process the resources into the destination directory, ready for packaging.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<compile>>> | compile the source code of the project.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-classes>>> | post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-test-sources>>> | generate any test source code for inclusion in compilation.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-sources>>> | process the test source code, for example to filter any values.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-test-resources>>> | create resources for testing.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-resources>>> | copy and process the resources into the test destination directory.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test-compile>>> | compile the test source code into the test destination directory
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test>>> | run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<package>>> | take the compiled code and package it in its distributable format, such as a JAR.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<integration-test>>> | process and deploy the package if necessary into an environment where integration tests can be run.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<verify>>> | run any checks to verify the package is valid and meets quality criteria.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<install>>> | install the package into the local repository, for use as a dependency in other projects locally.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<deploy>>> | done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
*-------------------------------+--------------------------------------------------------------------------------------+
* How the Build Lifecycle Affects Plugin Developers
The build lifecycle ensures that plugin developers only need to make their individual goal (a "mojo") perform a single
task with a simple set of inputs and outputs, and then have that goal bound to the appropriate stage of the build.
Information is passed between goals only through the project object - for example by adding new compile source roots,
changing the location of the classes directory after processing, and so on.
There are 3 ways that a plugin can interact with the build lifecycle: by binding a mojo to a particular phase, by
specifying an alternate packaging and appropriate lifecycle bindings, or by forking a parallel lifecycle.
** Binding a Mojo to a Phase
If the mojo is participating in a part of the normal build, usually the plugin developer will bind that mojo to a
particular phase, using the following syntax in the mojo level declaration:
----
@phase generate-sources
----
<<Note:>> <Some plugin languages have different ways of specifying mojo level declarations.
Please refer to the specific plugin development documentation for more information.>
Once this is specified, it will automatically be registered when the goal is listed in the project POM, as described
previously.
** Specifying a New Packaging
If your plugin is intended to provide a unique artifact type, then you will need to provide not only the goal to
package it with, but also a mapping of how the default lifecycle should behave.
This is currently achieved by adding a Plexus descriptor to your plugin (or modifying it if it already exists).
This file is <<<META-INF/plexus/components.xml>>> in the plugin JAR. The following is an example of configuring a
set of phases for the Plexus plugin itself to register the <<<plexus-application>>> type:
----
<component-set>
<components>
<component>
<role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
<role-hint>plexus-application</role-hint>
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
<configuration>
<phases>
<process-resources>resources:resources</process-resources>
<compile>compiler:compile</compile>
<process-test-resources>resources:testResources</process-test-resources>
<test-compile>compiler:testCompile</test-compile>
<test>surefire:test</test>
<package>plexus:app</package>
<install>install:install</install>
<deploy>deploy:deploy</deploy>
</phases>
</configuration>
</component>
</components>
</component-set>
----
In this example, the <<<role-hint>>> is used to specify the packaging, and the <<<role>>> of
<<<org.apache.maven.lifecycle.mapping.LifecycleMapping>>> indicates this is a lifecycle mapping for that packaging.
<<<implementation>>> is required, and while you can provide your own, the default given above should suit the standard case.
The phases to bind are listed in the configuration element, and each that is given can have one goal associated with
that phase for that particular packaging.
Once this is included in the JAR, the plugin needs to be added to the project to make the packaging available from
that project. In addition to listing the plugin, you must specify that it provides extensions:
----
...
<packaging>plexus-application</packaging>
...
<plugin>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-maven-plugin</artifactId>
<extensions>true</extensions>
</plugin>
...
----
Setting the extensions flag is also necessary if you provide custom artifact type handlers (closely related to
providing a packaging).
** Forking a Parallel Lifecycle
While lots of mojos will participate in the standard lifecycle, there are just as many that are used in other
scenarios. These are mojos that are executed standalone from the command line (such as <<<idea:idea>>>), or individual
reports in the site building process.
However, sometimes these goals require that a particular task has already been performed - for instance, the IDEA
plugin must ensure sources have been generated to properly construct its module files. If the goal were participating
in the lifecycle, it would easily do this by ensuring it occurred after the phase it depended on having run. Since
this isn't the case, it must have a way to first execute that task.
Additionally, even goals participating in the build lifecycle might need to perform a task with different parameters
to what was already used, and does not want the output to affect the current build (for example, running
<<<clover:check>>> to run tests with modified sources and fail if a certain coverage ratio is not achieved).
For these reasons, mojos are capable of forking a new lifecycle. The lifecycle will be a normal build lifecycle,
a clone of the one currently being used (including any additional bindings from the POM), executed up until the point
specified by the mojo.
For example, the <<<idea:idea>>> mojo specifies the following in the mojo level declarations to call the source
generation:
----
@execute phase="generate-sources"
----
But what happens if <<<generate-sources>>> has already been run in this build? In the current version of Maven, there
is no way to tell if the previous execution used the same input and outputs as the current mojo requires, so the task
(and any preceding ones if from the lifecycle) must be run again.
For this reason, it is important that if your plugin does any intensive work, you should first check whether it is
necessary to perform the tasks again, perhaps by using timestamp checking or a similar technique. As an example,
the compiler plugin will only recompile changed source files so can very efficiently be run multiple times in a build
if necessary.
When the lifecycle is forked, the project object being used is also cloned. In this way, modifications made to the
project as part of the execution, such as the addition of a new source root, will not affect the original build.
When the lifecycle finishes executing and control is passed to the original mojo, it can access that project using
the expression <<<${executedProject}>>>. For example:
----
/**
* @parameter expression="${executedProject}"
*/
private MavenProject executedProject;
----
This project instance can be used by the mojo to obtain results, and propogate any changes it sees fit into the
original build.
Finally, when forking the new lifecycle, it is possible to augment it on top of the changes already made by the
packaging and the plugins in the POM.
For example, consider the Clover plugin. If <<<clover:check>>> were to be run from the command line, the plugin
would need to fork the lifecycle, executing the <<<test>>> phase. But, it would also need to add some configuration
and bind the <<<clover:compiler>>> goal to the <<<generate-sources>>> phase.
This can be achieved by including the following file as <<<META-INF/maven/lifecycle.xml>>> in the plugin JAR:
----
<lifecycles>
<lifecycle>
<id>clover</id>
<phases>
<phase>
<id>generate-sources</id>
<executions>
<execution>
<configuration>
<debug>true</debug>
</configuration>
<goals>
<goal>compiler</goal>
</goals>
</execution>
</executions>
</phase>
</phases>
</lifecycle>
</lifecycles>
----
Here, the <<<executions>>> element is present in a similar way to a plugin declaration in the POM. This can be used
to bind a goal one or more times to a particular phase, as well as specifying configuration. Note that configuration
already provided in the POM to that plugin that is not part of a specific execution will also be applied.
The lifecycle ID given here (<<<clover>>>) can then be used in the mojo to specify what to overlay on the forked
lifecycle when executing it, using the following mojo level declaration:
----
@execute phase="test" lifecycle="clover"
----
For more information about plugin development in general, see the
{{{developers/plugin-overview.html} Developer's Section}}.

62
maven-site/src/site/apt/guides/introduction/introduction-to-the-pom.apt
View File

@ -1,62 +0,0 @@
------
Introduction to the POM
------
Jason van Zyl
------
12 October 2005
------
Introduction to the POM
* You need a Project Object Model (POM)
* Explain what is a POM is?
* Explain that the POM is the fundamental unit of work in Maven
* Explain the notion of the Super POM
* Show what a minimal POM can look like
* {{Super POM}}
%{snippet|id=superpom|url=http://svn.apache.org/repos/asf/maven/components/trunk/maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml}
+-----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
+-----+
* Project Inheritance
Elements in the POM that are merged are the following:
* dependencies
* developers and contributors
* plugin lists (including reports)
* plugin executions with matching ids
* plugin configuration
[]
<<NOTE:>> Profile inheritance the same inheritance strategy as used for the POM itself.

63
maven-site/src/site/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
View File

@ -1,63 +0,0 @@
------
Introduction to the Standard Directory Layout
------
Jason van Zyl
------
12 October 2005
------
Introduction to the Standard Directory Layout
Having a common directory layout would allow for users familiar with one Maven project to immediately feel
at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.
The next section documents the directory layout expected by Maven and the directory layout created by
Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can
be overridden via the project descriptor.
*--------------------------+-----------------------------------------------+
| src/main/java | Application/Library sources
*--------------------------+-----------------------------------------------+
| src/main/resources | Application/Library resources
*--------------------------+-----------------------------------------------+
| src/main/filters | Resource filter files
*--------------------------+-----------------------------------------------+
| src/main/assembly | Assembly descriptors
*--------------------------+-----------------------------------------------+
| src/main/config | Configuration files
*--------------------------+-----------------------------------------------+
| src/test/java | Test sources
*--------------------------+-----------------------------------------------+
| src/test/resources | Test resources
*--------------------------+-----------------------------------------------+
| src/test/filters | Test resource filter files
*--------------------------+-----------------------------------------------+
| src/site | Site
*--------------------------+-----------------------------------------------+
| LICENSE.txt | Project's license
*--------------------------+-----------------------------------------------+
| README.txt | Project's readme
*--------------------------+-----------------------------------------------+
At the top level files descriptive of the project: a <<<pom.xml>>> file (and any properties,
<<<maven.xml>>> or <<<build.xml>>> if using Ant). In addition, there are textual documents meant
for the user to be able to read immediately on receiving the source: <<<README.txt>>>,
<<<LICENSE.txt>>>, etc.
There are just two subdirectories of this structure: <<<src>>> and <<<target>>>. The only other
directories that would be expected here are metadata like <<<CVS>>> or <<<.svn>>>, and any
subprojects in a multiproject build (each of which would be laid out as above).
The <<<target>>>directory is used to house all output of the build.
The <<<src>>> directory contains all of the source material for building the project, its site and so on.
It contains a subdirectory for each type: <<<main>>> for the main build artifact, <<<test>>> for
the unit test code and resources, <<<site>>> and so on.
Within artifact producing source directories (ie. <<<main>>> and <<<test>>>), there is one
directory for the language <<<java>>> (under which the normal package hierarchy exists), and one for
<<<resources>>> (the structure under which is copied to the target classpath given the default resource definition).
If there are other contributing sources to the artifact build, they would be under other subdirectories: for
example <<<src/main/antlr>>> would contain Antlr grammar definition files.

60
maven-site/src/site/apt/guides/introduction/profile-example.txt
View File

@ -1,60 +0,0 @@
it's possible to do it with m2 beta-1 and profiles.
you declare profile in your pom like this :
<profiles>
<profile>
<id>env-test</id>
<activation>
<property>
<name>env</name>
<value>test</value>
</property>
</activation>
<properties>
<appProperties>test.properties</appProperties>
</properties>
</profile>
<profile>
<id>env-production</id>
<activation>
<property>
<name>env</name>
<value>production</value>
</property>
</activation>
<properties>
<appProperties>app.properties</appProperties>
</properties>
</profile>
</profiles>
and you can run mvn with one of profiles like :
mvn -P env-production clean:clean install ==> we use the profile id
or
mvn -Denv=test clean:clean install ==> we use the property env define in
<activation>
Emmanuel
martin.kuhn@merkur.at wrote:
> Hi,
>
> I'm a maven newbie and I try out maven 2.0 alpha 3.
>
> My questions:
>
> I have a project to build / deploy for three different enviroments (test,
> integration, production).
>
> The difference beetween the bundles is only a properties file (there are
> three different files: config-test.properties,
> config-integration.properties ...).
> In the build process I want to copy the right config file to a file with a
> common name (config.properties -> the app should work with this config
> file)
>
> Is there a solution to handle this with maven 2 or do I have to write a
> plugin?
>
>

599
maven-site/src/site/apt/guides/mini/guide-apt-format.apt
View File

@ -1,599 +0,0 @@
------
Guide to the APT Format
------
Jason van Zyl
------
12 October 2005
------
The APT format
~~~~~~~~~~~~~~
<<APT stands for "Almost Plain Text">>. APT is a format thats takes the hassle out
of writing documentation by striving for simplicity. APT syntax resembles
plain-text more than it resembles markup languages such as HTML, and the
following document contains some examples of available APT formatting.
The following sections contain formatted text that demonstrates the use
of APT to create paragraphs, headers, sections, lists, code samples,
figures, tables, rules, breaks, and text level elements such as font styles,
anchors, and special characters.
* Document structure
~~~~~~~~~~~~~~~~~~~~
A short APT document is contained in a single text file. A longer document
may be contained in a ordered list of text files. For instance, first text
file contains section 1, second text file contains section 2, and so on.
[Note:] Splitting the APT document in several text files on a section
boundary is not mandatory. The split may occur anywhere.
However doing so is recommended because a text file containing a
section is by itself a valid APT document.
A file contains a sequence of paragraphs and ``displays'' (non paragraphs
such as tables) separated by open lines.
A paragraph is simply a sequence of consecutive text lines.
+------------------------------------------------------------------------+
First line of first paragraph.
Second line of first paragraph.
Third line of first paragraph.
Line 1 of paragraph 2 (separated from first paragraph by an open line).
Line 2 of paragraph 2.
+------------------------------------------------------------------------+
The indentation of the first line of a paragraph is the main method used by
an APT processor to recognize the type of the paragraph. For example, a
section title must not be indented at all.
A ``plain'' paragraph must be indented by a certain amount of space. For
example, a plain paragraph which is not contained in a list may be indented
by two spaces.
+-------------------------------------------------+
My section title (not indented).
My paragraph first line (indented by 2 spaces).
+-------------------------------------------------+
Indentation is not rigid. Any amount of space will do. You don't even need
to use a consistent indentation all over your document. What really matters
for an APT processor is whether the paragraph is not indented at all or,
when inside a list, whether a paragraph is more or less indented than the
first item of the list (more about this later).
+-------------------------------------------------------+
First paragraph has its first line indented by four
spaces. Then the author did even bother to indent the
other lines of the paragraph.
Second paragraph contains several lines which are all
indented by two spaces. This style is much nicer than
the one used for the previous paragraph.
+-------------------------------------------------------+
Note that tabs are expanded with a tab width set to 8.
* Document elements
~~~~~~~~~~~~~~~~~~~
** Block level elements
~~~~~~~~~~~~~~~~~~~~~~~
*** Title
~~~~~~~~~~
A title is optional. If used, it must appear as the first block of the
document.
+----------------------------------------------------------------------------+
------
Title
------
Author
------
Date
+----------------------------------------------------------------------------+
A title block is indented (centering it is nicer). It begins with a line
containing at least 3 dashes (<<<--->>>).
After the first <<<--->>> line, one or several consecutive lines of text
(implicit line break after each line) specify the title of the document.
This text may immediately be followed by another <<<--->>> line and one or
several consecutive lines of text which specifies the author of the
document.
The author sub-block may optionaly be followed by a date sub-block using the
same syntax.
The following example is used for a document with an title and a date but
with no declared author.
+----------------------------------------------------------------------------+
------
Title
------
------
Date
------
+----------------------------------------------------------------------------+
The last line is ignored. It is just there to make the block nicer.
*** Paragraph
~~~~~~~~~~~~~
Paragraphs other than the title block may appear before the first section.
+----------------------+
Paragraph 1, line 1.
Paragraph 1, line 2.
Paragraph 2, line 1.
Paragraph 2, line 2.
+----------------------+
Paragraphs are indented. They have already been described in the {{document
structure}} section.
*** Section
~~~~~~~~~~~
Sections are created by inserting section titles into the document. Simple
documents need not contain sections.
+-----------------------------------+
Section title
* Sub-section title
** Sub-sub-section title
*** Sub-sub-sub-section title
**** Sub-sub-sub-sub-section title
+-----------------------------------+
Section titles are not indented. A sub-section title begins with one
asterisk (<<<*>>>), a sub-sub-section title begins with two asterisks
(<<<**>>>), and so forth up to four sub-section levels.
*** List
~~~~~~~~
+---------------------------------------+
* List item 1.
* List item 2.
Paragraph contained in list item 2.
* Sub-list item 1.
* Sub-list item 2.
* List item 3.
+---------------------------------------+
List items are indented and begin with a asterisk (<<<*>>>).
Plain paragraphs more indented than the first list item are nested in that
list. Displays such as tables (not indented) are always nested in the
current list.
To nest a list inside a list, indent its first item more than its parent
list. To end a list, add a paragraph or list item less indented than the
current list.
Section titles always end a list. Displays cannot end a list but the
<<<[]>>> pseudo-element may be used to force the end of a list.
+------------------------------------+
* List item 3.
Force end of list:
[]
--------------------------------------------
Verbatim text not contained in list item 3
--------------------------------------------
+------------------------------------+
In the previous example, without the <<<[]>>>, the verbatim text (not
indented as all displays) would have been contained in list item 3.
A single <<<[]>>> may be used to end several nested lists at the same
time. The indentation of <<<[]>>> may be used to specify exactly which
lists should be ended. Example:
+------------------------------------+
* List item 1.
* List item 2.
* Sub-list item 1.
* Sub-list item 2.
[]
-------------------------------------------------------------------
Verbatim text contained in list item 2, but not in sub-list item 2
-------------------------------------------------------------------
+------------------------------------+
There are three kind of lists, the bulleted lists we have already described,
the numbered lists and the definition lists.
+-----------------------------------------+
[[1]] Numbered item 1.
[[A]] Numbered item A.
[[B]] Numbered item B.
[[2]] Numbered item 2.
+-----------------------------------------+
A numbered list item begins with a label beetween two square brackets. The
label of the first item establishes the numbering scheme for the whole list:
[<<<[[1\]\]>>>] Decimal numbering: 1, 2, 3, 4, etc.
[<<<[[a\]\]>>>] Lower-alpha numbering: a, b, c, d, etc.
[<<<[[A\]\]>>>] Upper-alpha numbering: A, B, C, D, etc.
[<<<[[i\]\]>>>] Lower-roman numbering: i, ii, iii, iv, etc.
[<<<[[I\]\]>>>] Upper-roman numbering: I, II, III, IV, etc.
The labels of the items other than the first one are ignored. It is
recommended to take the time to type the correct label for each item in
order to keep the APT source document readable.
+-------------------------------------------+
[Defined term 1] of definition list 2.
[Defined term 2] of definition list 2.
+-------------------------------------------+
A definition list item begins with a defined term: text between square
brackets.
*** Verbatim text
~~~~~~~~~~~~~~~~~
+----------------------------------------+
----------------------------------------
Verbatim
text,
preformatted,
escaped.
----------------------------------------
+----------------------------------------+
A verbatim block is not indented. It begins with a non indented line
containing at least 3 dashes (<<<--->>>). It ends with a similar line.
<<<+-->>> instead of <<<--->>> draws a box around verbatim text.
Like in HTML, verbatim text is preformatted. Unlike HTML, verbatim text is
escaped: inside a verbatim display, markup is not interpreted by the APT
processor.
*** Figure
~~~~~~~~~~
+---------------------------+
[Figure name] Figure caption
+---------------------------+
A figure block is not indented. It begins with the figure name between
square brackets. The figure name is optionally followed by some text: the
figure caption.
The figure name is the pathname of the file containing the figure with an
extension. Example: <<</images/mylogo.jpeg>>>.
If the figure name comes from a relative pathname (recommended practice)
rather than from an absolute pathname, this relative pathname is taken to be
relative to the directory of the current APT document (a la HTML)
rather than relative to the current working directory.
*** Table
~~~~~~~~~
A table block is not indented. It begins with a non indented line containing
an asterisk and at least 2 dashes (<<<*-->>>). It ends with a
similar line.
The first line is not only used to recognize a table but also to specify
column justification. In the following example,
* the second asterisk (<<<*>>>) is used to specify that column 1 is
centered,
* the plus sign (<<<+>>>) specifies that column 2 is left aligned,
* the colon (<<<:>>>) specifies that column 3 is right aligned.
[]
+---------------------------------------------+
*----------*--------------+----------------:
| Centered | Left-aligned | Right-aligned |
| cell 1,1 | cell 1,2 | cell 1,3 |
*----------*--------------+----------------:
| cell 2,1 | cell 2,2 | cell 2,3 |
*----------*--------------+----------------:
Table caption
+---------------------------------------------+
Rows are separated by a non indented line beginning with <<<*-->>>.
An optional table caption (non indented text) may immediately follow the
table.
Rows may contain single line or multiple line cells. Each line of cell text
is separated from the adjacent cell by the pipe character (<<<|>>>).
(<<<|>>> may be used in the cell text if quoted: <<<\\|>>>.)
The last <<<|>>> is only used to make the table nicer. The first <<<|>>> is
not only used to make the table nicer, but also to specify that a grid is to
be drawn around table cells.
The following example shows a simple table with no grid and no caption.
+---------------+
*-----*------*
cell | cell
*-----*------*
cell | cell
*-----*------*
+---------------+
*** Horizontal rule
~~~~~~~~~~~~~~~~~~~
+---------------------+
=====================
+---------------------+
A non indented line containing at least 3 equal signs (<<<===>>>).
*** Page break
~~~~~~~~~~~~~~
+---+
^L
+---+
A non indented line containing a single form feed character (Control-L).
** Text level elements
~~~~~~~~~~~~~~~~~~~~~~
*** Font
~~~~~~~~
+-----------------------------------------------------+
<Italic> font. <<Bold>> font. <<<Monospaced>>> font.
+-----------------------------------------------------+
Text between \< and > must be rendered in italic. Text between \<\< and >>
must be rendered in bold. Text between \<\<\< and >>> must be rendered using
a monospaced, typewriter-like font.
Font elements may appear anywhere except inside other font elements.
It is not recommended to use font elements inside titles, section titles,
links and defined terms because a APT processor automatically applies
appropriate font styles to these elements.
*** Anchor and link
~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------+
{Anchor}. Link to {{anchor}}. Link to {{http://www.pixware.fr}}.
Link to {{{anchor}showing alternate text}}.
Link to {{{http://www.pixware.fr}Pixware home page}}.
+-----------------------------------------------------------------+
Text between curly braces (<<<\{}>>>) specifies an anchor. Text between
double curly braces (<<<\{\{}}>>>) specifies a link.
It is an error to create a link element that does not refer to an anchor of
the same name. The name of an anchor/link is its text with all non
alphanumeric characters stripped.
This rule does not apply to links to <external> anchors. Text beginning
with <<<http:/>>>, <<<https:/>>>, <<<ftp:/>>>, <<<file:/>>>, <<<mailto:>>>,
<<<../>>>, <<<./>>> (<<<..\\>>> and <<<.\\>>> on Windows) is recognized as
an external anchor name.
When the construct <<\{\{\{>><name><<}>><text><<}}>> is used, the link text
<text> may differ from the link name <name>.
Anchor/link elements may appear anywhere except inside other anchor/link
elements.
Section titles are implicitly defined anchors.
*** Line break
~~~~~~~~~~~~~~
+-------------+
Force line\
break.
+-------------+
A backslash character (<<<\\>>>) followed by a newline character.
Line breaks must not be used inside titles and tables (which are line
oriented blocks with implicit line breaks).
*** Non breaking space
~~~~~~~~~~~~~~~~~~~~~~
+----------------------+
Non\ breaking\ space.
+----------------------+
A backslash character (<<<\\>>>) followed by a space character.
*** Special character
~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------+
Escaped special characters: \~, \=, \-, \+, \*, \[, \], \<, \>, \{, \}, \\.
+---------------------------------------------------------------------------+
In certain contexts, these characters have a special meaning and therefore
must be escaped if needed as is. They are escaped by adding a backslash in
front of them. The backslash may itself be escaped by adding another
backslash in front of it.
Note that an asterisk, for example, needs to be escaped only if its begins a
paragraph. (<<<*>>> has no special meaning in the middle of a paragraph.)
+--------------------------------------+
Copyright symbol: \251, \xA9, \u00a9.
+--------------------------------------+
Latin-1 characters (whatever is the encoding of the APT document) may be
specified by their codes using a backslash followed by one to three octal
digits or by using the <<<\x>>><NN> notation, where <NN> are two hexadecimal
digits.
Unicode characters may be specified by their codes using the <<<\u>>><NNNN>
notation, where <NNNN> are four hexadecimal digits.
*** Comment
~~~~~~~~~~~
+---------------+
~~Commented out.
+---------------+
Text found after two tildes (<<<\~~>>>) is ignored up to the end of line.
A line of <<<~>>> is often used to ``underline'' section titles in order to
make them stand out of other paragraphs.
* The APT format at a glance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------------------------------------------------------
------
Title
------
Author
------
Date
Paragraph 1, line 1.
Paragraph 1, line 2.
Paragraph 2, line 1.
Paragraph 2, line 2.
Section title
* Sub-section title
** Sub-sub-section title
*** Sub-sub-sub-section title
**** Sub-sub-sub-sub-section title
* List item 1.
* List item 2.
Paragraph contained in list item 2.
* Sub-list item 1.
* Sub-list item 2.
* List item 3.
Force end of list:
[]
+------------------------------------------+
Verbatim text not contained in list item 3
+------------------------------------------+
[[1]] Numbered item 1.
[[A]] Numbered item A.
[[B]] Numbered item B.
[[2]] Numbered item 2.
List numbering schemes: [[1]], [[a]], [[A]], [[i]], [[I]].
[Defined term 1] of definition list.
[Defined term 2] of definition list.
+-------------------------------+
Verbatim text
in a box
+-------------------------------+
--- instead of +-- suppresses the box around verbatim text.
[Figure name] Figure caption
*----------*--------------+----------------:
| Centered | Left-aligned | Right-aligned |
| cell 1,1 | cell 1,2 | cell 1,3 |
*----------*--------------+----------------:
| cell 2,1 | cell 2,2 | cell 2,3 |
*----------*--------------+----------------:
Table caption
No grid, no caption:
*-----*------*
cell | cell
*-----*------*
cell | cell
*-----*------*
Horizontal line:
=======================================================================
^L
New page.
<Italic> font. <<Bold>> font. <<<Monospaced>>> font.
{Anchor}. Link to {{anchor}}. Link to {{http://www.pixware.fr}}.
Link to {{{anchor}showing alternate text}}.
Link to {{{http://www.pixware.fr}Pixware home page}}.
Force line\
break.
Non\ breaking\ space.
Escaped special characters: \~, \=, \-, \+, \*, \[, \], \<, \>, \{, \}, \\.
Copyright symbol: \251, \xA9, \u00a9.
~~Commented out.
------------------------------------------------------------------------------

151
maven-site/src/site/apt/guides/mini/guide-assemblies.apt
View File

@ -1,151 +0,0 @@
------
Guide to Creating Assemblies
------
Jason van Zyl
------
12 October 2005
------
Guide to creating assemblies
The assembly mechanism in Maven 2.x provides an easy way to create distributions using a assembly descriptor
and dependency information found in you POM. In order to use the assembly plug-in you need to configure the
assembly plug-in in your POM and it might look like the following:
+----+
<project>
<parent>
<artifactId>maven</artifactId>
<groupId>org.apache.maven</groupId>
<version>2.0-beta-3-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<name>Maven Embedder</name>
<version>2.0-beta-3-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptor>src/main/assembly/dep.xml</descriptor>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+
You'll notice that the assembly descriptor is located in <<<${basedir}/src/main/assembly>>> which is the
{{{../introduction/introduction-to-the-standard-directory-layout.html}standard}} location for assembly
descriptors.
* Creating a binary assembly
This is the most typical usage of the assembly plugin where you are creating a distribution for standard
use.
+----+
<assembly>
<id>bin</id>
<formats>
<format>tar.gz</format>
<format>tar.bz2</format>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<includes>
<include>README*</include>
<include>LICENSE*</include>
<include>NOTICE*</include>
</includes>
</fileSet>
<fileSet>
<directory>target</directory>
<outputDirectory></outputDirectory>
<includes>
<include>*.jar</include>
</includes>
</fileSet>
</fileSets>
</assembly>
+----+
+----+
<assembly>
<!-- TODO: a jarjar format would be better -->
<id>dep</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<outputDirectory>/</outputDirectory>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>/</outputDirectory>
<unpack>true</unpack>
<scope>runtime</scope>
<excludes>
<exclude>junit:junit</exclude>
<exclude>commons-lang:commons-lang</exclude>
<exclude>commons-logging:commons-logging</exclude>
<exclude>commons-cli:commons-cli</exclude>
<exclude>jsch:jsch</exclude>
<exclude>org.apache.maven.wagon:wagon-ssh</exclude>
<!-- TODO: can probably be removed now -->
<exclude>plexus:plexus-container-default</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
+----+
+----+
<assembly>
<id>src</id>
<formats>
<format>tar.gz</format>
<format>tar.bz2</format>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<includes>
<include>README*</include>
<include>LICENSE*</include>
<include>NOTICE*</include>
<include>pom.xml</include>
</includes>
</fileSet>
<fileSet>
<directory>src</directory>
</fileSet>
</fileSets>
</assembly>
+----+
+----+
mvn assembly:assembly
+----+
+----+

80
maven-site/src/site/apt/guides/mini/guide-attached-tests.apt
View File

@ -1,80 +0,0 @@
------
Guide to using attached tests
------
Jason van Zyl
------
12 October 2005
------
Guide to using attached tests
Many times you may want to resuse the tests that you have created for a project in another. For example if you have
written <<<foo-core>>> and it contains test code in the <<<${basedir}/src/test/java>>> it would be useful to package
up those compiled tests in a JAR and deploy them for general resuse. To do this you would configure the
<<<maven-jar-plugin>>> as follows:
+----+
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
+----+
* Installing the attached test JAR
In order to install the attached test JAR you simply use the standard install phase by executing
the following command:
+----+
mvn install
+----+
* Deploying the attached test JAR
In order to deploy the attached test JAR you simply use the standard deploy phase by executing
the following command:
+----+
mvn deploy
+----+
* Using the attached test JAR
In order to use the attached test JAR that was created above you simply specify a dependency on the main
artifact with a specified type of <<<test-jar>>>:
+----+
<project>
...
<dependencies>
<dependency>
<groupId>com.myco.app</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
</dependency>
</depdendnecies>
...
</project>
+----+

53
maven-site/src/site/apt/guides/mini/guide-bash-m2-completion.apt
View File

@ -1,53 +0,0 @@
------
Guide to Maven 2.x auto completion using BASH
------
Trygve Laugstol
Jason van Zyl
------
12 October 2005
------
Guide to Maven 2.x auto completion using BASH
First you must go to the following site to install the BASH programmable
auto completion setup if your distro doesn't have it by default. I don't
think many do so you'll need to go {{{http://www.caliban.org/bash/index.shtml#completion}here}}.
Once you've setup your system for auto completion you need to take the
following:
+----+
#!/bin/bash
_m2_make_goals()
{
plugin=$1
mojos=$2
for mojo in $mojos
do
export goals="$goals $plugin:$mojo"
done
}
_m2_complete()
{
local cur goals
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
goals='clean compile test install package deploy site'
goals=$goals _m2_make_goals "eclipse" "eclipse"
goals=$goals _m2_make_goals "idea" "idea"
goals=$goals _m2_make_goals "assembly" "assembly"
goals=$goals _m2_make_goals "plexus" "app bundle-application bundle-runtime descriptor runtime service"
cur=`echo $cur | sed 's/\\\\//g'`
COMPREPLY=($(compgen -W "${goals}" ${cur} | sed 's/\\\\//g') )
}
complete -F _m2_complete -o filenames mvn
+----+
And place it in <<</etc/bash_completion.d/m2>>>. Once you've done that the
next time you start up your BASH shell you will have m2 auto completion!

233
maven-site/src/site/apt/guides/mini/guide-configuring-plugins.apt
View File

@ -1,233 +0,0 @@
------
Guide to Configuring Plug-ins
------
Jason van Zyl
------
12 October 2005
------
Guide to Configuring Plug-ins
In Maven plug-ins are configured by specifying a <<<configuration>>> element where the child elements of the
<<<configuration>>> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in consists of
one or more Mojos where a Mojo maps to a goal). Say, for example, we had a Mojo that performed a query against
a particular URL, with a specified timeout and list of options. The Mojo might look like the following:
+----+
public class MyQueryMojo
extends AbstractMojo
{
/**
* @parameter
*/
private String url;
/**
* @parameter
*/
private int timeout;
/**
* @parameter
*/
private String[] options;
public void execute()
throws MojoExecutionException
{
...
}
}
+----+
To configure the Mojo from your POM with the desired URL, timeout and options you might have something like
the following:
+----+
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-myquery-plugin</artifactId>
<configuration>
<url>http://www.foobar.com/query</url>
<timeout>10</timeout>
<options>
<option>one</option>
<option>two</option>
<option>three</option>
</options>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+
As you can see the elements in the configuration match the names of the fields in the Mojo. The configuration
mechanism Maven employs is very similar to the way {{{http://xstream.codehaus.org}XStream}} works where elements
in XML are mapped to objects. So from the example above you can see that the mapping is pretty straight forward the
<<<url>>> element maps to the <<<url>>> field, the <<<timeout>>> element maps to the <<<timeout>>> field and the
<<<options>>> element maps to the <<<options>>> field. The mapping mechanism can deal with arrays by inspecting
the type of the field and determining if a suitable mapping is possible.
* Mapping complex objects
Mapping complex types is also fairly straight forward in Maven so let's look at a simple example where we
are trying to map a configuration for Person object. The <<<configuration>>> element might look like the
following:
+----+
...
<configuration>
<person>
<firstName>Jason</firstName>
<lastName>van Zyl</lastName>
</person>
</configuration>
...
+----+
The rules for mapping complex objects are as follows:
* There must be a private field that corresponds to name of the element being mapped. So in our case the
<<<person>>> element must map to a <<<person>>> field.
* The object instantiated must be in the same package as the Mojo itself. So if your mojo is in
<<<com.mycompany.mojo.query>>> then the mapping mechanism will look in that package for an
object named <<<Person>>>. As you can see the mechanism will capitalize the first letter of
the element name and use that to search for the object to instantiate.
* If you wish to have the object to be instantiated live in a different package or have a more
complicated name then you must specify this using an <<<implementation>>> attribute like the
following:
[]
+----+
...
<configuration>
<person implementation="com.mycompany.mojo.query.SuperPerson">
<firstName>Jason</firstName>
<lastName>van Zyl</lastName>
</person>
</configuration>
...
+----+
* Mapping to collections
The configuration mapping mechanism can easily deal with most collections so let's go through a few examples
to show you how it's done:
** Mapping lists
Mapping lists works in much the same way as mapping to arrays where you a list of elements will be
mapped to the List. So if you have a mojo like the following:
+----+
public class MyAnimalMojo
extends AbstractMojo
{
/**
* @parameter
*/
private List animals;
public void execute()
throws MojoExecutionException
{
...
}
}
+----+
Where you have a field named <<<animals>>> then your configuration for the plug-in would look like the following:
+----+
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-myanimal-plugin</artifactId>
<configuration>
<animals>
<animal>cat</animal>
<animal>dog</animal>
<animal>aardvark</animal>
</options>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+
Where each of the animals listed would be entries in the <<<animals>>> field. If there is no <<<Animal>>> class
present then the field is assume to be of type <<<java.lang.String>>>.
** Mapping maps
** Mapping properties
* Using setters
You are not restricted to using private field mapping which is good if you are trying to make you Mojos resuable
outside the context of Maven. Using the example above we could name our private fields using the underscore
convention and provide setters that the configuration mapping mechanism can use. So our Mojo would look
like the following:
+----+
public class MyQueryMojo
extends AbstractMojo
{
/**
* @parameter property="url"
*/
private String _url;
/**
* @parameter property="timeout"
*/
private int _timeout;
/**
* @parameter property="options"
*/
private String[] _options;
public void setUrl( String url ){ _url = url; }
public void setTimeout( int timeout ){ _timeout = timeout; }
public void setOptions( String[] options ){ _options = options; }
public void execute()
throws MojoExecutionException
{
...
}
}
+----+
Note the specification of the property name which tells Maven what setter and getter to use when the field
is not accessed directly.

70
maven-site/src/site/apt/guides/mini/guide-coping-with-sun-jars.apt
View File

@ -1,70 +0,0 @@
------
Guide to Coping with Sun JARs
------
Jason van Zyl
------
12 October 2005
------
Coping with SUN JARs
Often users are confronted with the need to build against JARs provide by
SUN like the {{{http://java.sun.com/products/javamail/}JavaMail}} JAR, or the
{{{http://java.sun.com/products/javabeans/glasgow/jaf.html}Activation}} JAR
and users have found these JARs not present in central repository resulting
in a broken build. Unfortunately most of these artifacts fall under Sun's
Binary License which disallows us from distributing them from Ibiblio.
Another problem is that Sun's appears not to have any sort of convention
for naming their own JARs so we have taken steps in suggesting some common
names for Sun's artifacts. You can find a list of our suggestions here:
*-------------------------------------------+-------------------+----------------+
|Product artifact | Group ID | Artifact ID
*-------------------------------------------+-------------------+----------------+
| Java Activation Framework | javax.activation | activation
*-------------------------------------------+-------------------+----------------+
| J2EE | javax.j2ee | j2ee
*-------------------------------------------+-------------------+----------------+
| JCA | javax.jca | jca
*-------------------------------------------+-------------------+----------------+
| JDO | javax.jdo | jdo
*-------------------------------------------+-------------------+----------------+
| JMS | javax.jms | jms
*-------------------------------------------+-------------------+----------------+
| JavaMail | javax.mail | mail
*-------------------------------------------+-------------------+----------------+
| EJB 3 | javax.persistence | ejb
*-------------------------------------------+-------------------+----------------+
| J2EE Connector Architecture | javax.resource | connector-api
*-------------------------------------------+-------------------+----------------+
| Java Authorization Contract for Containers| javax.security | jacc
*-------------------------------------------+-------------------+----------------+
| Servlet | javax.servlet | servlet-api
*-------------------------------------------+-------------------+----------------+
| Servlet JSP | javax.servlet | jsp-api
*-------------------------------------------+-------------------+----------------+
| Servlet JSTL | javax.servlet | jstl
*-------------------------------------------+-------------------+----------------+
| JDBC 2.0 Optional Package | javax.sql | jdbc-stdext
*-------------------------------------------+-------------------+----------------+
| Java Transaction API (JTA) | javax.transaction | jta
*-------------------------------------------+-------------------+----------------+
| Java XML RPC | javax.xml | jaxrpc
*-------------------------------------------+-------------------+----------------+
| Portlet | javax.portlet | portlet-api
*-------------------------------------------+-------------------+----------------+
| JNDI | javax.naming | jndi
*-------------------------------------------+-------------------+----------------+
When you add a Sun dependency to your POM if you use the our suggestions
as noted above then Maven 2.x can help you locate the JARs by providing
the site where they can be retrieved. It is important that you follow
the suggested naming conventions as we cannot store the JARs at Ibiblio we
can store metadata about those JARs and it is the metadata that contains
location and retrieval information.
Once you have downloaded a particular SUN JAR to your system you can install the JAR
in your local repository. Please refer to our {{{guide-installing-3rd-party-jars.html}Guide to installing 3rd party JARs}}
for instructions on how to accomplish this.

166
maven-site/src/site/apt/guides/mini/guide-creating-archetypes.apt
View File

@ -1,166 +0,0 @@
------
Guide to Creating Archetypes
------
Jason van Zyl, Alexander Hars
------
26 October 2005
------
Guide to Creating Archetypes
Creating an archetype is a pretty straight forward process. An archetype is a very simple plugin, that
contains the project prototype you wish to create. An archetype is made up of:
* an archetype descriptor (<archetype.xml> in directory: <src/main/resources/META-INF/>). It lists all the files
that will be contained in the archetype and categorizes them so they can be processed correctly by the
archetype generation mechanism.
* the prototype files that are copied by the archetype (directory: <src/main/resources/archetype-resources/>)
* the prototpye pom (<pom.xml> in: <src/main/resourcs/archetype-resources>)
* a pom for the archetype (<pom.xml> in the archetype's root directory).
[]
To create an archetype follow these steps:
* 1. Create a new project and pom.xml for the archetype plugin
An example <pom.xml> for an archetype plugin looks as follows:
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>my.groupId<groupId>
<artifactId>my-archetype-id</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>maven-plugin</packaging>
</project>
+----+
All you need to specify is a <groupId>, <artifactId> and <version>. These three parameters will be needed later for
invoking the archetype via <archetype:create> from the commandline.
* 2. Create the archetype descriptor
The archetype descriptor is a file called <archetype.xml> which must be located in <src/main/resources/META-INF/>
An example for an archetype descriptor can be found in the quickstart archetype:
+----+
<archetype>
<id>quickstart</id>
<sources>
<source>src/main/java/App.java</source>
</sources>
<testSources>
<source>src/test/java/AppTest.java</source>
</testSources>
</archetype>
+----+
The \<id\> tag should be the same as the artifactId in the archetype <pom.xml>.
An optional \<allowPartial\>true\</allowPartial\> tag makes it possible to run the archetype:create even existing projects.
The \<sources\>, \<resources\>, \<test-resources\> and \<site-resources\> tags represent the different sections of the project:
* \<sources\> = src/main/java
* \<resources\> = src/main/resources
* \<test-sources\> = src/test/java
* \<test-resources\> = src/test/resources
* \<site-resources\> = src/site
[]
\<sources\> and \<test-sources\> can contain \<source\> elements that specify a source file.
\<test-resources\> and \<site-resources\> can contain \<resource\> elements that specify a resource file.
At this point one can only specify individual files to be created but not empty directories.
Thus the quickstart archetype shown above defines the following directory structure:
+----+
archetype
|-- pom.xml
`-- src
`-- main
`-- resources
|-- META-INF
| `-- archetype.xml
`-- archetype-resources
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- App.java
`-- test
`-- java
`-- AppTest.java
+----+
* 3. Create the prototype files and the prototype pom.xml
The next component of the archetype to be created is the prototype <pom.xml>. Any <pom.xml> will do, just
don't forget to the set <artifactId> and <groupId> as variables ( <$\{artifactId\}> / <$\{groupId\}> ). Both variables
will be initialized from the commandline when calling <archetype:create>.
An example for a prototype <pom.xml> is:
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>${groupId}</groupId>
<artifactId>${artifactId}</artifactId>
<packaging>jar</packaging>
<version>${version}</version>
<name>A custom project</name>
<url>http://www.myorganization.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
+----+
* 4. Install and run the archetype
Now you are ready to install the archetype:
+----+
mvn install
+----+
Now that you have created an archetype you can try it on your local system by using the following command:
In this command, you need to specify the full information about the archetype you want to use (its groupId, its artifactId, its version) and the information about the new project you want to create (artifactId and groupId).
Don't forget to include the version of your archetype (if you don't include the version, you archetype creation may fail with a message that version:RELEASE was not found)
+----+
mvn archetype:create -DarchetypeGroupId=<archetype-groupId> -DarchetypeArtifactId=<archetype-artifactId> \
-DarchetypeVersion=<archetype-version> -DgroupId=<my.groupid> -DartifactId=<my-artifactId>
+----+
Once you are happy with the state of your archetype you can deploy (or submit it to ibiblio) it as any other artifact and
the archetype will then be available to any user of Maven.

93
maven-site/src/site/apt/guides/mini/guide-deploy-ftp.apt
View File

@ -1,93 +0,0 @@
------
Guide to deploying with FTP
------
Jason van Zyl
------
12 October 2005
------
Guide to deploying with FTP
In order to deploy artifacts using FTP you must first specify the use of an FTP server in the
<<distributionManagement>> element of your POM as well as specifying an <<<extension>>> in your
<<<build>>> element which will pull in the FTP artifacts required to deploy with FTP:
+----+
<project>
<parent>
<groupId>com.stchome</groupId>
<artifactId>mavenFull</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.1-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<!-- Enabling the use of FTP -->
<distributionManagement>
<repository>
<id>ftp-repository</id>
<url>ftp://repository.mycompany.com/repository</url>
</repository>
</distributionManagement>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-3</version>
</extension>
</extensions>
</build>
</project>
+----+
Your <<<settings.xml>>> would contain a <<<server>>> element where the <<<id>>> of that element matches <<<id>>> of the
FTP repository specified in the POM above:
+----+
<settings>
...
<servers>
<server>
<id>ftp-repository</id>
<username>user</username>
<password>pass</password>
</server>
</servers>
...
</settings>
+----+
You should, of course, make sure that you can login into the specified FTP server by hand before attempting the
deployment with Maven. Once you have verified that everything is setup correctly you can now deploy your artifacts
using Maven:
+----+
mvn deploy
+----+

72
maven-site/src/site/apt/guides/mini/guide-deploy-ssh-external.apt
View File

@ -1,72 +0,0 @@
------
Guide to deploying with an external SSH command
------
Jason van Zyl
------
12 October 2005
------
Guide to deploying with an external SSH command
In order to deploy artifacts using FTP you must first specify the use of an FTP server in the
<<distributionManagement>> element of your POM as well as specifying an <<<extension>>> in your
<<<build>>> element which will pull in the FTP artifacts required to deploy with FTP:
+----+
<project>
<parent>
<groupId>com.stchome</groupId>
<artifactId>mavenFull</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.1-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<!-- Enabling the use of FTP -->
<distributionManagement>
<repository>
<id>ssh-repository</id>
<url>scpexe://repository.mycompany.com/repository</url>
</repository>
</distributionManagement>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh-external</artifactId>
<version>1.0-alpha-5</version>
</extension>
</extensions>
</build>
</project>
+----+
Using the external ssh command means you don't need any additional configuration in your <<<settings.xml>>>
file as everything will be taken from the environment.
You should, of course, make sure that you can login into the specified SSH server by hand before attempting the
deployment with Maven. Once you have verified that everything is setup correctly you can now deploy your artifacts
using Maven:
+----+
mvn deploy
+----+

44
maven-site/src/site/apt/guides/mini/guide-deployment-security-settings.apt
View File

@ -1,44 +0,0 @@
------
Guide to Deployment and Security Settings
------
Jason van Zyl
------
12 October 2005
------
Security and Deployment Settings
Repositories to deploy to are defined in a project in the <<<distributionManagement>>> section. However, you cannot put
your username, password, or other security settings in that project. For that reason, you should add a server
definition to your own settings with an id that matches that of the deployment repository in the project.
In addition, some repositories may require authorisation to download from, so the corresponding settings can be
specified in a server element in the same way.
Which settings are required will depend on the type of repository you are deploying to. As of the first release,
only SCP deployments and file deployments are supported by default, so only the following SCP
configuration is needed:
+-----+
<settings>
.
.
<servers>
<server>
<id>repo1</id>
<username>repouser</username>
<!-- other optional elements:
<password>my_login_password</password>
<privateKey>/path/to/identity</privateKey> (default is ~/.ssh/id_dsa)
<passphrase>my_key_passphrase</passphrase>
-->
</server>
</servers>
.
.
</settings>
+-----+
<<Note>>: the settings descriptor documentation can be found {{{../../maven-settings/settings.html}here}}.

48
maven-site/src/site/apt/guides/mini/guide-ear.apt
View File

@ -1,48 +0,0 @@
------
Guide to EARs
------
Jason van Zyl
------
12 October 2005
------
+----+
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-ear
+----+
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-webapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<finalName>my-webapp</finalName>
</build>
</project>
+----+
Note the <packaging> element - this tells Maven to build as a WAR. Change into the webapp project's directory and try:
+----+
mvn clean package
+----+
You'll see target/my-webapp.war is built, and that all the normal steps were executed.
Now you can modify this webapp project and turn it into anything you need!

69
maven-site/src/site/apt/guides/mini/guide-embedding-m2.apt
View File

@ -1,69 +0,0 @@
------
Guide to Embedding Maven 2.x
------
Jason van Zyl
------
12 October 2005
------
Embedding Maven 2.x
The Maven Embedder is intended to be the single component that tool
integrators will need to access all the features of Maven. The Maven Embedder
is currently a work in progress but is advancing rapidly as it is being used
for a Maven 2.x plugin for Eclipse. The Maven Embedder will be release in its
final form after the final release of Maven 2.0 itself.
Here are some of the features provided by the Maven Embedder:
* Reading/writing <<<pom.xml>>> files as models
* Reading/writing <<<pom.xml>>> files as projects
* Retrieval of standard lifecycle phases
* Retrieval of plugin metadata
* Execution of Maven
[]
+----+
public class Plugin
{
public Plugin()
throws Exception
{
MavenEmbedder maven = new MavenEmbedder();
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
maven.setClassLoader( classLoader );
maven.setLogger( new MavenEmbedderConsoleLogger() );
maven.start();
File targetDirectory = new File( System.getProperty( "user.dir" ), "target/embedder-test-project" );
File pomFile = new File( targetDirectory, "pom.xml" );
MavenProject pom = maven.readProjectWithDependencies( pomFile );
EventMonitor eventMonitor = new DefaultEventMonitor( new PlexusLoggerAdapter( new MavenEmbedderConsoleLogger() ) );
maven.execute( pom, Collections.singletonList( "package" ), eventMonitor, new ConsoleDownloadMonitor(), null, targetDirectory );
}
public static void main( String[] args )
throws Exception
{
Plugin plugin = new Plugin();
}
}
+----+
There are many known issues with the embedder and you can find them
{{http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10500&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&component=11850}here}}.

53
maven-site/src/site/apt/guides/mini/guide-generating-sources.apt
View File

@ -1,53 +0,0 @@
------
Guide to generating Sources
------
Jason van Zyl
------
12 October 2005
------
Guide to generating sources
Let's run though a short example to try and help. To generate sources you must first have a plugin that
participates in the generate-sources phase like the Antlr plugin:
%{snippet|id=generate-sources-0|url=http://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-antlr-plugin/src/main/java/org/apache/maven/plugin/antlr/AntlrPlugin.java}
The first two lines say "I want to be fit into the generate-sources
phase and my 'handle' is generate".
So this is all fine and dandy, we have a plugin that wants to generate some sources from a Antlr grammar but how
do we use it. You need to specify that you want to use it in your POM:
+----+
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antlr-plugin</artifactId>
<configuration>
<grammars>java.g</grammars>
</configuration>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
+----+
If you then type "mvn compile" m2 will walk through the {{{../introduction/introduction-to-the-lifecycle.html}lifecycle}}
and will eventually hit the <<<generate-sources>>> phase and see you have a plugin configured that
wants to participate in that phase and the antlr plugin is executed with
your given configuration.

167
maven-site/src/site/apt/guides/mini/guide-ibiblio-upload.apt
View File

@ -1,167 +0,0 @@
------
Guide to uploading artifacts to Ibiblio
------
Jason van Zyl
------
12 October 2005
------
Guide to uploading artifacts to Ibiblio
In order for users of Maven to utilize artifacts produced by your project you must deploy them to
a remote repository. Many open source projects want to allow users of their projects who build with
Maven to have transparent access to their project's artifacts. In order to allow for this a project
must have their artifacts deployed the Ibiblio which acts as Maven's central global repostory.
* Step 1: Create an upload bundle
Use the repository plugin provided with the standard Maven distribution to create an upload bundle:
+----+
mvn repository:bundle-create
+----+
The bundle will be created in your <<<target>>> directory of the form:
<<<${pom.artifactId}-${pom.currentVersion}-bundle.jar>>>
If you are not using maven as your build system but want something
uploaded to Ibiblio then you just need to make a JAR (using the <<<jar>>> executable,
not <<<zip>>>, <<<pkzip>>> or equivalent) with the following format:
+----+
LICENSE.txt
pom.xml
foo-1.0.jar (or whatever artifact is referred to in the pom.xml)
+----+
Note that the bundle will be read by a script, so it must follow the above format. Also,
the <<<pom.xml>>> should at least contain the following elements:
* modelVersion
* groupId
* artifactId
* packaging
* name
* version
* url
* scm url
* description
* dependencies
A basic sample:
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.maven</groupId>
<artifactId>maven</artifactId>
<version>2.0</version>
<packaging>jar</packaging>
<name>Maven core</name>
<url>http://maven.apache.org</url>
<description>The maven main core project description</description>
<scm>
<url>http://svn.apache.org/viewcvs.cgi/maven</url>
</scm>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
</dependency>
...
<dependencies>
</project>
+----+
[]
Some considerations about the <<groupId>>: it will identify your project uniquely across all
projects, so we need to enforce a naming schema. For projects with artifacts already uploaded to ibiblio it can
be equal to the previous used, but for new projects it has to follow the package name rules, what
means that has to be at least as a domain name you control, and you can create as many subgroups
as you want. Look at {{{http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.7}
More information about package names}}. Check also the guide about
{{{guide-naming-conventions.html}Maven naming conventions}}
Examples:
* www.springframework.org -> org.springframework
* oness.sf.net -> net.sf.oness
[]
* Step 2: Posting the request
Post your request to {{{http://jira.codehaus.org/secure/CreateIssue.jspa?pid=10367&amp;issuetype=3}JIRA}}.
In the description you should write the URL of the upload bundle
(if you're uploading more than one bundle please add all the urls under the same issue),
then leave a blank line and provide the following:
* a url where the project can be found.
* if you are one of its developers, a url where your name or email can be found inside the project site.
[]
This will speed up the uploading process.
You can place any additional comments you wish in the following paragraph. So the description field might look like:
+----+
http://wiggle.sourceforge.net/downloads/wiggle-1.0-bundle.jar
http://wiggle.sourceforge.net
http://wiggle.sourceforge.net/team-list.html
Wiggle is a fantastic new piece of software for automating the
clipping of nose hairs. Please upload!
+----+
* Explanation
Some folks have asked why do we require the POM and license each time an artifact is deployed so here's a small explanation. The POM
being deployed with the artifact is part of the process to make transitive dependencies a reality in Maven. The logic for getting
transitive dependencies working is really not that hard, the problem is getting the data. The other applications
that may be possible having all the POMs available for artifacts are vast, so by placing them into the repository as part of the
process we open up the doors to new ideas that involve unified
access to project POMs.
We also ask for a license now because it is possible that your project's license may change in the course of
its life time and we are trying create tools to help normal people sort out licensing issues. For example, knowing all the licenses
for a particular graph of artifacts we could have some strategies that would identify potential licensing problems.
* Maven partners
The following sites sync automatically their project repository with the central one.
If you want a project from any of this sites to be uploaded to ibiblio you'll have to
contact the project maintainers.
* {{{http://www.apache.org}The Apache Software Foundation}}
* {{{http://www.codehaus.org}Codehaus}}
* {{{http://jetty.mortbay.org}MortBay Jetty}}
* {{{http://www.opensymphony.com/}OpenSymphony}}
* {{{http://www.osjava.org}OS Java}}

233
maven-site/src/site/apt/guides/mini/guide-ide-eclipse.apt
View File

@ -1,233 +0,0 @@
------
Guide to using Eclipse with Maven 2.x
------
Bernd Mau, mau@hhla.de
------
28 October 2005
------
Guide to using Eclipse with Maven 2.x
This mini guide explains howto use Maven 2 in Eclipse IDE.
* {{{#Maven 2 repository}Maven 2 repository}}
* {{{#Maven as an external tool}Maven as an external tool}}
* {{{#Simple Project}Simple Project}}
* {{{#Multiple Module Project}Multiple Module Project}}
* {Maven 2 repository}
Eclipse needs to know the path to the local maven
repository. Therefore the classpath variable <M2_REPO> has to be
set. Execute the following command:
+----+
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo
+----+
You can also define a new classpath variable inside eclipse: From the
menu bar, select Window > Preferences. Select the Java > Build Path >
Classpath Variables page.
<<Issue:>> The command does not work. Aside from it should not require a POM.
* {Maven as an external tool}
You might want to execute some maven goals from inside eclipse. This
is possible by configuring an external launcher. It is best practice
to prepare eclipse by adding a variable, which points to your local
maven excutable (mvn.bat/mvn). From the menu bar, select Window >
Preferences. Select the Run/Debug > String Substitution. Add a new
variable e.g. <maven_exec>. When you set up a new external launcher
(from the menu bar, select Run > External Tools. Select Program) you
can refer to <maven_exec> in the location field. Furhtermore refer to
<project_loc> as the working directory and specify the maven goals of
your choice as arguments, e.g. <eclipse:eclipse>. For further
information please refer to the eclipse help.
<<Issue:>> Would be nice, if the plugin generates the variable and a runner.
* {Simple Project}
If you have a simple java project which is made up of only one
module, using eclipse is very simple. To generate the eclipse project
files from your POM you execute the following command:
+----+
mvn eclipse:eclipse
+----+
If you have created or checked out the project with eclipse, you only
have to refresh the project in your workspace. Otherwise you have to
import the project into your eclipse workspace (From the menu bar,
select File >Import >Existing Projects into Workspace). In the
latter case the project (directory) should not be located in your
workspace, because eclipse might come into trouble, especially if you
want to use eclipse as the scm client.
* {Multiple Module Project}
Due to the workspace idea many eclipse users are used to a flat
layout and therefore want to keep this structure, which is possible
but not recommended. Actually, the only reason for a {{{#Flat Project
Layout}flat multiple module project layout}} is the possibility to
checkout and edit the parent POM without checking out the whole
project. The following sample shows how to handle maven multiple
module projects with eclipse while keeping the
{{{http://maven.apache.org/guides/mini/guide-multi-module.html}recommended
hierachical project layout}}.
** {Step by Step from Scratch}
Supposing eclipse is your favorite SCM client, this step by step
example shows how to set up a new mutiple module project.
[[1]] Set up a new eclipse workspace called <step-by-step> and add
the <M2_REPO> classpath variable as {{{#Maven 2 repository}described
above}}.
[[1]] Open the command line shell and change to the newly created workspace directory.
[[1]] From the command line change to newly created <step-by-step>
workspace and create a new maven project using the archetype plugin.
+----+
mvn archetype:create -DgroupId=guide.ide.eclipse -DartifactId=guide-ide-eclipse
+----+
[[1]] Create a new simple project <guide-ide-eclipse> inside the
<step-by-step> workspace with eclipse (From the menu bar, select
File >New >Project. Select Simple >Project). Eclipse will
create a simple <.project>-file for your <guide-ide-eclipse>-project
and you should be able to see the <pom.xml>-file.
[[1]] Delete the <src>-folder and open the <pom.xml>-file to change
the packaging of your parent project to <pom>
+----+
<packaging>pom</packaging>
+----+
<<Issue:>> mvn eclipse:eclipse may should generate a simple
<.project>-file for pom types.
[[1]] From the command line change to the <guide-ide-eclipse> project
directory and create some modules.
+----+
cd guide-ide-eclipse
mvn archetype:create -DgroupId=guide.ide.eclipse -DartifactId=guide-ide-eclipse-site
mvn archetype:create -DgroupId=guide.ide.eclipse.core -DartifactId=guide-ide-eclipse-core
mvn archetype:create -DgroupId=guide.ide.eclipse.module1 -DartifactId=guide-ide-eclipse-module1
+----+
[[1]] Add the newly created modules to your parent pom.
+----+
<modules>
<module>guide-ide-eclipse-site</module>
<module>guide-ide-eclipse-core</module>
<module>guide-ide-eclipse-module1</module>
</modules>
+----+
[[1]] Add the parent to the POMs of the new modules:
+----+
<parent>
<groupId>guide.ide.eclipse</groupId>
<artifactId>guide-ide-eclipse</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
+----+
[[1]] Add dependency from <module1> to the <core>-module:
+----+
<dependency>
<groupId>guide.ide.eclipse.core</groupId>
<artifactId>guide-ide-eclipse-core</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
+----+
[[1]] Install the project in your local repository and generate the eclipse files:
+----+
mvn install
mvn eclipse:eclipse
+----+
[[1]] Check in your project using the eclipse team support (select
from the context menu Team >Share Project). <Note:> Don not check
in the generated eclipse files. If you use CVS you should have a
<.cvsignore>-file with the following entries for each module:
+----+
target
.classpath
.project
.wtpmodules
+----+
Even the parent project should have this <.cvsignore>-file. Eclipse
will automatically generate a new simple <.project>-file when you
check out the project from the repository.
<<Issue:>> Plugin should optionally generate the <.cvsignore>-files.
[]
From now on you have different options to proceed. If you are working
on all modules simultanously and you rather have eclipse project
dependencies than binary dependencies, you should set up a new workspace
and import all projects form <step-by-step/guide-ide-eclipse>. Note,
you have to delete the <.project>-file of your parent project
before. The result is equals to checking out the whole project from
the command line, running <mvn eclipse:eclipse> and finally importing
the projects into your eclipse workspace. In both cases you will be
able to synchronize your changes using eclipse.
In case of large projects whith many people it can be quite tedious
to check out all modules and keep them up to date. Especially if you
are only interested in one or two modules. In this case using binary
dependencies is much more comfortable. Just check out the modules you
want to work on with eclipse and run <mvn eclipse:eclipse> for each
module (see also {{{#Maven as an external tool}Maven as an external
tool}}). Of course all referenced artifacts have to be available from
your maven repository.
<<Issue:>> The maven-eclipse-plugin should optionally generate
project dependencies for those modules which are available in the
workspace.
** {Flat Project Layout}
It is possible to move the parent POM in its own directory on the
same level with the referenced modules.
[[1]] Create a new directory under <guide-ide-eclipse> called
<guide-ide-eclipse-project> and move the parent POM to it.
[[1]] Change the module references in the parent POM to:
+----+
<modules>
<module>../guide-ide-eclipse-site</module>
<module>../guide-ide-eclipse-core</module>
<module>../guide-ide-eclipse-module1</module>
</modules>
+----+
[]
<<Issue:>> The release plugin does not support the flat structure
({{{http://jira.codehaus.org/browse/MNG-1263}MNG-1263}})

17
maven-site/src/site/apt/guides/mini/guide-ide-idea.apt
View File

@ -1,17 +0,0 @@
------
Guide to using IDEA with Maven 2.x
------
Jason van Zyl
------
12 October 2005
------
Guide to using IDEA with Maven 2.x
To generate the IDEA project files from your POM you execute the following command:
+----+
mvn idea:idea
+----+

251
maven-site/src/site/apt/guides/mini/guide-ide-netbeans/guide-ide-netbeans.apt
View File

@ -1,251 +0,0 @@
------
Guide to Using maven 2 in Netbeans 4.0 (4.1 and 5.0)
------
Rapha<68>l Pi<50>roni
------
Mon Aug 9 2005
------
Using maven 2 in Netbeans 4.0 (4.1 and 5.0)
This mini guide explain by examples howto use Maven 2 in Netbeans IDE.
To use Maven 2 in Netbeans you have to follow these steps:
* {{{#Retreive/Create the Maven 2 project}Retreive/Create the Maven 2 project.}}
* {{{#Launch Maven 2 in command line using the netbeans-freeform plugin}Launch Maven 2 in command line using the netbeans-freeform plugin.}}
* {{{#Open the project with Netbeans}Open the project with Netbeans.}}
* {{{#Build the project and launch other Maven goals}Build the project and launch other Maven goals.}}
* {{{#Edit properties of the plugin}Edit properties of the plugin.}}
* {{{#Refresh the project view}Refresh the project view.}}
* {{{#Build the Maven 2 site}Build the Maven 2 site.}}
* {Retreive/Create the Maven 2 project}
This guide assume the project is created using the archetype plugin.
You can also checkout the Maven 2 project using your versionning system.
-------------------
[maven-user@mini-guide examples]$ mvn archetype:create -DarchetypeArtifactId=maven-archetype-quickstart -DartifactId=demoquickstart -DgroupId=demoquickstart
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [archetype:create] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] **************************************************************
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties
[INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader.
[INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm'
[INFO] Velocimacro : VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed.
[INFO] Velocimacro : messages on : VM system will output logging messages
[INFO] Velocimacro : autoload off : VM system will not automatically reload global library macros
[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[INFO] [archetype:create]
[INFO] Defaulting package to group ID: demoquickstart
[INFO] artifact org.apache.maven.archetypes:maven-archetype-quickstart: checking for updates from central
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating Archetype: maven-archetype-quickstart:RELEASE
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: demoquickstart
[INFO] Parameter: outputDirectory, Value: /demos/demoquickstart
[INFO] Parameter: packageName, Value: demoquickstart
[INFO] Parameter: package, Value: demoquickstart
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: artifactId, Value: demoquickstart
[INFO] ResourceManager : found archetype-resources/pom.xml with loader org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ********************* End of debug info from resources from generated POM ***********************
[INFO] ResourceManager : found archetype-resources/src/main/java/App.java with loader org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ResourceManager : found archetype-resources/src/test/java/AppTest.java with loader org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] Archetype created in dir: /demos/demoquickstart
[INFO] ----------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Oct 11 21:59:22 CEST 2005
[INFO] Final Memory: 3M/7M
[INFO] ----------------------------------------------------------------------------
-------------------
* {Launch Maven 2 in command line using the netbeans-freeform plugin}
After having retreived the Maven 2 project, you have to eneable the project to
be seen as a Netbeans 4.0, 4.1 or 5.0 project using the Netbeans Freeform project type.
To eneable the project, use the netbeans-freeform plugin for Maven 2.
-------------------
[maven-user@mini-guide demoquickstart]$ mvn netbeans-freeform:generate-netbeans-project
[INFO] Searching repository for plugin with prefix: 'netbeans-freeform'.
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Quick Start Archetype
[INFO] task-segment: [netbeans-freeform:generate-netbeans-project]
[INFO] ----------------------------------------------------------------------------
[INFO] Preparing netbeans-freeform:generate-netbeans-project
[INFO] [netbeans-freeform:generate-netbeans-project]
[INFO] JarAnalyser found
[INFO] The project 'Maven Quick Start Archetype' is analysed.
[INFO] The file 'nbproject/project.xml' is created.
[INFO] The file 'nbproject/mavencall.xml' is created.
[INFO] The file 'nbproject/project.properties' is created.
[INFO] ----------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Oct 11 22:12:30 CEST 2005
[INFO] Final Memory: 1M/3M
[INFO] ----------------------------------------------------------------------------
-------------------
The netbeans-freeform plugin creates one directory and three files by reading the Maven 2 project descriptor:
* The <<<nbproject>>> directory holds the Netbeans project descriptor.
* The <<<<project.xml>>> file is the Netbeans Freeform project descriptor.
* The <<<mavencall.xml>>> holds the Ant calls which execute Maven 2, as Netbeans uses Ant as its build tool.
* The <<<project.properties>>> files holds the two properties: <<<local.repository>>>
which is the absolute path to the Maven 2 local repository and <<<project.directory>>>
which is the absolute path to the project directory.
* {Open the project with Netbeans}
Now that the Maven 2 project is eneabled for use in Netbeans, open your Netbeans IDE.
Then open the project (Ctrl+Maj+O).
Here is the <Open Project> window.
[Open_Project.png] Open Project
And here are:
The <Projects Window> with the opened project.
[Project_Opened.png] Project Opened
The project's <Context Menu> of the opened project.
[Context_Menu.png] Context Menu
And the <Files Window> with the opened project.
[Window_Files.png] Files Window
* {Build the project and launch other Maven goals}
It is now time to try the first execution of Maven 2 from within Netbeans.
Try the <Build Main Project> Netbeans action (F11).
You see the Maven 2 execution of the <<<package>>> lifecycle goal.
[Run_Build_Main_Project.png] Run Build Main Project
You can also call the <Clean Project> Netbeans action which is mapped to the <<<clean:clean>>> Maven2 goal.
[Run_Clean_Main_Project.png] Run Clean Main Project
* {Edit properties of the plugin}
Now you can add some additionnal views in your <Projects> window in Netbeans.
Like an additionnal goal in the context menu.
-------------------
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>demoquickstart</groupId>
<artifactId>demoquickstart</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>netbeans-freeform-maven-plugin</artifactId>
<configuration>
<additionalGoals>source:jar</additionalGoals>
</configuration>
</plugin>
</plugins>
</build>
</project>
-------------------
You can also configure some additionnal files and folders in the <Projects> window.
The last option is to create the <<<nbproject>>> folder and its content in another directory than in the Maven 2 project's one.
The full configuration can be found at {{http://mojo.codehaus.org/netbeans-freeform-maven-plugin}}.
* {Refresh the project view}
To refresh the Project view in Netbeans accordingly to the new configuration added to the Maven 2 project descriptor.
Just right-clic the project in the Projects window and choose the <Refresh Project> action.
[Refresh_Project.png] Refresh Project
Here is the resulting refreshed Context Menu.
[Refreshed_Context_Menu.png] Refreshed Context Menu
* {Build the Maven 2 site}
You can call The <Generate Javadoc for Project> Netbeans action which is mapped to the <<<site:site>>> Maven 2 goal,
here in the Maven site archetype.
[Generate_Site.png] Generate Site

22
maven-site/src/site/apt/guides/mini/guide-installing-3rd-party-jars.apt
View File

@ -1,22 +0,0 @@
------
Guide to installing 3rd party JARs
------
Jason van Zyl
------
12 October 2005
------
Guide to installing 3rd party JARs
Often times you will have 3rd party JARs that you need to put in your local repository for use in your
builds. The JARs must be placed in the local repository in the correct place in order for it to be correctly
picked up by Maven. To make this easier, and then error prone, we have provide a goal in the install plug-in
which should make this relatively painless. To install a JAR in the local repository use the following
command:
+----+
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> \
-DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>
+----+

175
maven-site/src/site/apt/guides/mini/guide-m1-m2.apt
View File

@ -1,175 +0,0 @@
-----
Guide to Moving From Maven 1.x to Maven 2.x
---
Jay H. Hartley
-----
12 October 2005
-----
Guide to Moving from Maven 1.x to Maven 2.x
This document is intended to be continously updated from the mail list archives.
For an only slightly out-of-date reference with concrete examples,
check out Vincent Massol's
{{{http://blogs.codehaus.org/people/vmassol/archives/001170_javazone_2005.html}JavaZone2005 presentation}}.
* Parallel Builds
It is possible to establish parallel Maven builds, one using the old M1 settings,
and a second using M2. The Maven 2 configuration file names and uses have been modified,
so the two builds should not conflict.
A Maven 1.x build is configured with the following files:
* [project.xml] Project Object Model (POM) definition
* [maven.xml] Custom build scripts
* [project.properties] general build settings
* [build.properties] local build settings
A Maven 2 build is configured with a different file set:
* [pom.xml] POM definition
* [settings.xml] local configuration
* Migrating the POM
The Project Object Model (POM) has moved from the project.xml file to pom.xml.
The XML schema has also changed, from {{{http://maven.apache.org/maven-v3_0_0.xsd}Version 3}} to
{{{http://maven.apache.org/maven-v4_0_0.xsd}Version 4}}.
The new POM is nominally a superset of the old, so the first step in creating a
pom.xml is to copy over project.xml. Then start tweaking.
There are several new elements that can be added to a POM, but all are optional so
should not cause a problem with an initial build.
project.xml:
+----+
<project>
<pomVersion>3</pomVersion>
<id>util</id>
<name>Generic utility code</name>
<groupId>project</groupId>
<currentVersion>1.1</currentVersion>
<package>org.apache.project.util</package>
<dependencies>
...
</dependencies>
<build>
...
</build>
...
</project>
+----+
pom.xml:
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>util</artifactId>
<name>Generic Utility Code</name>
<groupId>org.apache.project.util</groupId>
<version>1.1</version>
<packaging>jar</packaging>
<dependencies>
...
</dependencies>
<build>
...
</build>
...
</project>
+----+
For more details, check out the
{{{http://maven.apache.org/maven2/guides/introduction/introduction-to-the-pom.html}POM Guide}}.
* build.properties and project.properties
These files have been replaced with
{{{http://maven.apache.org/maven2/maven-settings/settings.html}settings.xml}}.
Like with the POM, you can establish a parallel build environment, so the m1 build
never breaks while the m2 build is being debugged.
Additional local build customization options can also be created using
{{{http://maven.apache.org/maven2/guides/introduction/introduction-to-profiles.html}profiles}}.
* What to do with maven.xml?
See {{http://maven.apache.org/maven2/maven1.html#m1-maven-xml}} for an explanation of
why maven.xml was discarded, and
{{http://maven.apache.org/maven2/guides/introduction/introduction-to-plugins.html}} for
a guide to writing your own plug-ins.
* Directory Structure
The POM allows customization of the directory structure in both Maven 1 and Maven 2
using the <<<\<build\>>>> tag. For simplicity, it would be ideal to move source to the
{{{http://maven.apache.org/maven2/guides/introduction/introduction-to-the-standard-directory-layout.html}Maven 2 default structure}},
but it is not required. You can begin by customizing the
directories in Maven 2, then when satisfied that both build paths are working, move
to the Maven 2 structure and customize the settings in Maven 1.
* Migrating Plug-ins
The main conceptual change in plugins and their use has to do with the concept of
a build cycle in Maven 2. Instead of using <<<preGoal>>> and <<<postGoal>>> tags
in <<<maven.xml>>> to tie plugin goals into the build process, the goals of a
plugin are associated with the pre-defined stages of the build cycle. See the
{{{http://maven.apache.org/maven2/guides/introduction/introduction-to-the-lifecycle.html}Introduction to the Build Lifecycle}}
for more on how plugins relate.
** Re-use Ant Tasks
See the {{{http://maven.apache.org/maven2/general.html#using-ant-tasks}Ant Script FAQ}}.
** Replace scripts with Mojos
The new plugin architecture does not specify a specific language implementation, so
Jelly scripts and other such artifacts should be re-usable with wrappers. It is recommended
that you look into moving to
{{{http://maven.apache.org/maven2/guides/plugin/guide-java-plugin-development.html}Mojos}}.
** Utilize built-in Maven 2 capabilities
*** Resource filtering to inject POM variables into application
You can turn on {{{http://maven.apache.org/maven2/guides/getting-started/index.html#How do I filter resource files?}resource filtering}}
in your POM. Tokens of the form <<<$\{pom.variable\}>>> in resource files will be replaced with the corresponding POM property.
+----+
<project>
...
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
+----+
*** Multiproject Builds
The old reactor+multiproject plugin combination was established more as an afterthought
of the core development. In Maven 2, multiproject support is included in the core, so
any scripts required in the past to work around problems with the multiproject plugin
should be unnecessary.
* Migrating repositories
Every four hours the Maven 1.x repository is converted over to a Maven 2.x repository and we plan to release
a plug-in based on our conversion tool but currently

130
maven-site/src/site/apt/guides/mini/guide-manifest.apt
View File

@ -1,130 +0,0 @@
------
Guide to Working with Manifests
------
Jason van Zyl
------
12 October 2005
------
Guide to Working with Manifests
In order to modify the manifest of the resultant JAR produced by the jar plug-in you need to create a configuration
for the jar plug-in. In this first example we'll add some entries to the manifest by specifying what we'd like
in the <<<configuration>>> element of the jar plug-in:
+----+
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+
As you see above you can use literal values or you can have values from the POM interpolated into literals
or simply use straight POM expressions. So this is what your resultant <<<MANIFEST.MF>>> will look like inside
the generated JAR:
+----+
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: jvanzyl
Build-Jdk: 1.4.2_09
Extension-Name: my-app
Specification-Vendor: MyCompany Inc
Implementation-Vendor: MyCompany Inc
Implementation-Title: my-app
Implementation-Version: 1.0-SNAPSHOT
mode: development
url: http://maven.apache.org
+----+
If you need to do more then simply add some manifest entries there are more options like activating indexing of the
JAR, setting the main-class, packageName ... Here's an example of what the <<<configuration>>> element of the
JAR plug-in might look like:
+----+
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<!--
<index>true</true>
-->
<manifest>
<mainClass>com.mycompany.app.App</mainClass>
<packageName>com.mycompany.app</packageName>
<!-- options
<manifestFile>/path/to/MANIFEST.MF</manifestFile>
<addClasspath>true</addClasspath>
<addExtensions/>
<classpathPrefix/>
-->
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+
So this is what your resultant <<<MANIFEST.MF>>> will look like inside the generated JAR:
+----+
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: jvanzyl
Package: org.com.foo.app
Build-Jdk: 1.4.2_09
Extension-Name: my-app
Specification-Vendor: MyCompany Inc
Implementation-Vendor: MyCompany Inc
Implementation-Title: my-app
Implementation-Version: 1.0-SNAPSHOT
Main-Class: org.com.foo.App
mode: development
url: http://maven.apache.org
+----+
~~ suggestion by jorg
~~ it would be nice if the Specification-Version could be easily generated to be major.minor of pom.currentVersion i.e. that
~~
~~ 1.2 ==> 1.2
~~ 1.2.1 ==> 1.2
~~ 1.2-SNAPSHOT ==> 1.2
~~ for the javaapp-plugin I did something like this in Jelly ...

45
maven-site/src/site/apt/guides/mini/guide-maven-classloading.apt
View File

@ -1,45 +0,0 @@
------
Guide to Maven Classloading
------
Jason van Zyl
------
12 October 2005
------
How Maven's classloaders work
Maven uses the {{{http://classworlds.codehaus.org}Classworlds}} classloading framework with which we
create our classloader graph. If you look in your <<<${maven.home}/m2/core>>> directory you will see a single JAR
which is the classworlds JAR we use to boot the classloader graph. The Classworlds JAR is the only element of
the Java $CLASSPATH and Classworlds then builds the following graph of classloaders where the <<<plexus.core>>> classloader,
or Realm in Classworlds, is the parent in the context of Maven.
+----+
[plexus.core]
${maven.home}/core/*.jar
^
|
|
[plexus.core.maven]
${maven.home}/lib/*.jar
^
|
|
[per plugin]
+----+
The top level classloader contains plexus container and plexus utils, and also has access to Classworlds.
The next classloader down the graph contain the core requirements of Maven. In general these are just Maven libraries.
We hope to further separate these in the future to just be Maven APIs and have the implementations selected at
runtime as required by the system.
After that, each plugin has its own classloader, including its dependencies, itself, and the libraries above.
It *does not* contain the project dependencies as in Maven 1.x, but instead has access to a list of JAR files in case
they are needed.
In addition, a project can list <<extensions>>. These are loaded into <<<[plexus.maven.core]>>> classloader and
so available to the Maven core and all plug-ins for the current project and subsequent projects (in the future,
we plan to remove it from subsequent projects).

69
maven-site/src/site/apt/guides/mini/guide-maven-evangelism.apt
View File

@ -1,69 +0,0 @@
------
Guide to Maven Evangelism
------
Carlos Sanchez
------
31 October 2005
------
Guide to add, improve or fix metadata in the ibiblio maven 2 repository
Checkout with subversion the poms you need from
<<<svn://svn.codehaus.org/maven/scm/repository>>>
(note that this subversion repo has a lot of files and folders)
Fix the poms and open an issue at {{{http://jira.codehaus.org/browse/MEV}JIRA}} with
a patch file from subversion in unified diff format, explaining the reasons why
it needs to be changed (there were no dependencies, wrong info,...).
Developers information
The developer connection to the subversion pom repository is at
<<<svn+ssh://[username]@svn.codehaus.org/home/projects/maven/scm/repository>>>
It only contains m2 poms (manually added), and this poms will overwrite everything in the maven2 repo.
If a pom doesn't exist or has just the basic information (eg. was autogenerated) patches can be applied.
If it has already information, dependencies,... a consensus has to be reached. NEVER will be changed
a pom with the <status> tag set to "verified".
Information about the current configuration
The canonical repository is at <<<beaver.codehaus.org>>>, under <<</home/projects/maven>>>
* repository-staging/to-ibiblio/maven - maven 1 repo
* repository-staging/to-ibiblio/maven2 - maven 2 repo
Every 4 hours a crontab runs
<<<$HOME/repository-tools/synchronize.sh 2>&1 | tee $HOME/repository-tools/last-sync-results.txt>>>
Folder contents:
* <<<components>>> - svn checkout from maven/components svn
* <<<components/maven-meeper/src/bin/deploy-bundle>>> script to deploy an upload bundle from JIRA MAVENUPLOAD
* <<<components/maven-meeper/src/bin/syncopate/>>> scripts to rsync from partner repos
* <<<components/maven-meeper/src/bin/syncopate/conf/>>> syncopate configuration for each of the partners
* <<<components/maven-meeper/src/bin/ibiblio-sync/>>> scripts to rsync to and from ibiblio
* <<<repository-tools/ibiblio-sync/>>> link to components/maven-meeper/src/bin/ibiblio-sync/
* <<<repository-tools/synchronize.sh>>> link to components/maven-meeper/src/bin/synchronize.sh
* <<<repository-tools/repoclean>>> snapshot of the repoclean tool
<<<https://svn.apache.org/repos/asf/maven/components/trunk/sandbox/repoclean>>>

47
maven-site/src/site/apt/guides/mini/guide-mirror-settings.apt
View File

@ -1,47 +0,0 @@
------
Guide to Mirror Settings
------
Jason van Zyl
------
12 October 2005
------
Using Mirrors for Repositories
Repositories are declared inside a project, which means that if you have your own custom repositories, those sharing
your project easily get the right settings out of the box. However, you may want to use an alternative mirror
for a particular repository without changing the project files.
Some reasons to use a mirror are:
* There is a synchronized mirror on the internet that is geographically closer and faster
* You want to replace a particular repository with your own internal repository which you have greater control over
* You want to run maven-proxy to provide a local cache to a mirror and need to use it's URL instead
To configure a mirror of a given repository, you provide it in your settings file, giving the new repository it's
own id and url , and specify the mirrorOf setting that is the ID of the repository you are using a
mirror of. For example, the ID of the main Maven repository included by default is central, so to use
an Australian mirror, you would configure the following:
+-----+
<settings>
.
.
<mirrors>
<mirror>
<id>planetmirror</id>
<name>Australian Mirror of http://repo1.maven.org/maven2/</name>
<url>http://public.planetmirror.com/maven2/</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
.
.
</settings>
+-----+
<<Note>>: the settings descriptor documentation can be found {{{../../maven-settings/settings.html}here}}.

11
maven-site/src/site/apt/guides/mini/guide-multi-module.apt
View File

@ -1,11 +0,0 @@
------
Guide to creating a multi-module build
------
Jason van Zyl
------
12 October 2005
------
Guide to creating a multi-module build
In progress.

88
maven-site/src/site/apt/guides/mini/guide-multiple-repositories.apt
View File

@ -1,88 +0,0 @@
------
Guide to using Multiple Repositories
------
Jason van Zyl
------
12 October 2005
------
Setting up Multiple Repositories
There are two different ways that you can specify the use of multiple repositories. The first
way is to specify in a POM which repositories you want to use:
+----+
<project>
...
<repositories>
<repository>
<id>my-repo1</id>
<name>your custom repo</name>
<url>http://jarsm2.dyndns.dk</url>
</repository>
<repository>
<id>my-repo2</id>
<name>your custom repo</name>
<url>http://jarsm2.dyndns.dk</url>
</repository>
</repositories>
...
</project>
+----+
The <<<repositories>>> element is inherited so you would usually specify the repositories
to use for a group of projects by defining a <<<repositories>>> element at the top of your
inheritance chain.
<<NOTE:>> You will also get the standard set of repositories as defined in the
{{{../introduction/introduction-to-the-pom.html#Super POM}Super POM}}.
The other way you can specify the use of multiple repositories by creating a profile in
your <<<~/.m2/settings.xml>>> file like the following:
+----+
<settings>
...
<profiles>
...
<profile>
<id>myprofile</id>
<repositories>
<repository>
<id>my-repo2</id>
<name>your custom repo</name>
<url>http://jarsm2.dyndns.dk</url>
</repository>
</repositories>
</profile>
...
</profiles>
<activeProfiles>
<activeProfile>myprofile</activeProfile>
</activeProfiles>
...
</settings>
+----+
If you specify repositories in profiles you must remember to activate that
particular profile! As you can see above we do this by registering a profile
to be active in the <<<activeProfiles>>> element.
You could also activate this profile on the command like by executing the following
command:
+----+
mvn -Pmyprofile ...
+----+
In fact the <<<-P>>> option will take a CSV list of profiles to activate if you wish to
activate multiple profiles simultaneously.
<<Note>>: the settings descriptor documentation can be found {{{../../maven-settings/settings.html}here}}.

32
maven-site/src/site/apt/guides/mini/guide-naming-conventions.apt
View File

@ -1,32 +0,0 @@
------
Guide to Naming Conventions
------
Carlos Sanchez
------
1 November 2005
------
Guide to naming conventions on groupId, artifactId and version
[]
* <<groupId>> it will identify your project uniquely in internet
so we need to enforce a naming schema. It has to follow the package name rules, what
means that has to be at least as a domain name you control, and you can create as many subgroups
as you want. Look at {{{http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.7}
More information about package names}}.
eg. <<<org.apache.maven>>>, <<<org.apache.jakarta.commons>>>
* <<artifactId>> the name of the jar without version. If you created it then you can choose
whatever name you want with lowercase letters and no strange symbols. If it's a third party jar
you have to take the name of the jar as it's distributed.
eg. <<<maven>>>, <<<commons-math>>>
* <<version>> if you distribute it then you can choose any typical version with numbers and dots
(1.0, 1.1, 1.0.1, ...).
Don't use dates as they are usually associated with snapshot (nightly) builds. If it's a third
party artifact, you have to use their version number whatever it is, and as strange it can look.
eg. <<<2.0>>>, <<<2.0.1>>>, <<<1.3.1>>>

43
maven-site/src/site/apt/guides/mini/guide-proxies.apt
View File

@ -1,43 +0,0 @@
------
Guide to using proxies
------
Jason van Zyl
------
12 October 2005
------
Configuring a proxy
You can configure a proxy to use for some or all of your HTTP requests in Maven 2.0. The username and password are only
required if your proxy requires basic authentication (note that later releases may support storing your passwords in
a secured keystore - in the mean time, please ensure your settings.xml file is secured with permissions
appropriate for your operating system).
The nonProxyHosts setting accepts wild cards, and each host not to proxy is separated by the | character. This matches
the JDK configuration equivalent.
+----+
<settings>
.
.
<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
<host>proxy.somewhere.com</host>
<port>8080</port>
<username>proxyuser</username>
<password>somepassword</password>
<nonProxyHosts>www.google.com|*.somewhere.com</nonProxyHosts>
</proxy>
</proxies>
.
.
</settings>
+----+
Please note that urrently NTML proxies are not supported as they have not been tested.
<<Note>>: the settings descriptor documentation can be found {{{../../maven-settings/settings.html}here}}.

81
maven-site/src/site/apt/guides/mini/guide-releasing.apt
View File

@ -1,81 +0,0 @@
-----
Guide to Releasing
-----
Jason van Zyl
-----
12 October 2005
-----
~~ integrate releasing document
Releasing
The release plugin provides some basic functionality for making releases, and updating
the project SCM accordingly. A release is performed in 2 steps:
[[1]] Preparing the release.
[[2]] Performing the release.
[]
Preparing the release
The <<<release:prepare>>> goal will:
[[1]] Verify that there are no uncommitted changes in the checkout
[[2]] Prompt for a desired version and tag name
[[3]] Modify the pom.xml
[[4]] Tag the entire source tree with the new tag name
[]
-----
mvn release:prepare -DtagBase=svn+ssh://svn.codehaus.org/home/projects/plexus/scm/tags
-----
When this operation is over, your source control has the released code tagged and ready to deploy.
Performing the release
-----
mvn release:perform -DtagBase=svn+ssh://svn.codehaus.org/home/projects/plexus/scm
-----
~~ -----
~~ o had to update each component manually to change the version
~~ o had to change the depMan element in the top-level POM
~~ both tedious and error prone
~~ o had to change the assembly file name
~~ o had to change the webpapp file name
~~ sign the release
-----
#!/bin/sh
rel=$1
if [ -z "$rel" ]; then
echo usage: $0 release
exit 1
fi
exts="tar.gz tar.bz2 zip"
if [ -f "$rel.exe" ]; then
exts="$exts exe"
fi
for i in $exts; do md5sum $rel.$i | sed 's/ .*$//g' >$rel.$i.md5; done
for i in $exts; do gpg --armor --output $rel.$i.asc --detach-sig
$rel.$i; done
-----
~~ o deploy to /www/www.apache.org/dist/maven/binaries
~~ o even though we have said each module needs to specify its own version that
~~ is really a pita. maybe there is a better way we can deal with that.

242
maven-site/src/site/apt/guides/mini/guide-site.apt
View File

@ -1,242 +0,0 @@
------
Guide to creating a site
------
Brett Porter
Jason van Zyl
------
13 May 2005
------
Creating a site
* Creating Content
The first step to creating your site is to create some content. In Maven 2.0, the site content is separated by format,
as there are several available.
-------------------
+- src/
+- site/
+- apt/
| +- index.apt
|
+- xdoc/
| +- other.xml
|
+- fml/
| +- general.fml
| +- faq.fml
|
+- site.xml
--------------------
The Xdoc format is the same as {{{http://maven.apache.org/using/site.html} used in Maven 1.0}}. However, <<<navigation.xml>>>
has been replaced by the site descriptor (see below).
The APT format, "Almost Plain Text", is a wiki-like format that allows you to write simple, structured documents (like this)
very quickly. A full reference of the {{{apt-format.html} APT Format}} is available.
The FML format is the FAQ format, also used in Maven 1.0.
Other formats are available, but at this point these 3 are the best tested. There are also several possible output formats,
but as of 2.0, only XHTML is available.
Note that all of the above is optional - just one index file is required in one of the input trees. Each of the paths will be merged
together to form the root directory of the site.
* Generating The Site
Generating the site is very simple, and fast!
---------------
mvn site
---------------
The resulting site will be in <<<target/site/...>>>
For more information on the site plugin, see the {{{../../plugins/maven-site-plugin/} plugin reference}}.
* Deploying The Site
To be able to deploy the site, you must first declare a location to distribute to in your <<<pom.xml>>>, similar to the repository for
deployment.
---------------
<distributionManagement>
<site>
<id>website</id>
<url>scp://www.mycompany.com/www/docs/project/</url>
</site>
</distributionManagement>
---------------
The <<<id>>> element identifies the repository, so that you can attach credentials to it in your <<<settings.xml>>>
file in the same way as you would for any other repository. The URL gives the location to deploy to. Currently,
only SSH is supported, as above which copies to the host <<<www.mycompany.com>>> in the path <<</www/docs/project/>>>.
---------------
mvn site-deploy
---------------
<<Note:>> the trailing slash in the URL above indicates that any subprojects that inherit this value should append their artifact ID to
the path instead of using it as-is.
* Creating a Site Descriptor
The <<<site.xml>>> file is used to describe the layout of the site, and replaces the navigation file used in Maven 1.0.
A sample is given below:
--------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven">
<bannerLeft>
<name>Maven</name>
<src>http://maven.apache.org/images/apache-maven-project.png</src>
<href>http://maven.apache.org/</href>
</bannerLeft>
<bannerRight>
<src>http://maven.apache.org/images/maven-small.gif</src>
</bannerRight>
<body>
<links>
<item name="Apache" href="http://www.apache.org/" />
<item name="Maven 1.0" href="http://maven.apache.org/"/>
<item name="Maven 2" href="http://maven.apache.org/maven2/"/>
</links>
<menu name="Maven 2.0">
<item name="Introduction" href="index.html"/>
<item name="Download" href="download.html"/>
<item name="Release Notes" href="release-notes.html" />
<item name="General Information" href="about.html"/>
<item name="For Maven 1.0 Users" href="maven1.html"/>
<item name="Road Map" href="roadmap.html" />
</menu>
${reports}
...
</body>
</project>
--------------------
~~TODO: deserves more explanation.
Note the <<<${reports}>>> string in the navigation. When building the site, this is replaced by menus for any reports
that you have configured.
* Adding Extra Resources
You can add any arbitrary resources to you site by including them in a
<<<resources>>> directory as shown below. Additional CSS files will be picked up
when they are placed in the <<<css>>> directory within the <<<resources>>>
directory.
-------------------
+- src/
+- site/
+- resources/
+- css/
| +- site.css
|
+- images/
+- pic1.jpg
--------------------
The file <<<site.css>>> will be added to the default XHTML output, so can be used to adjust the default Maven stylesheets if desired.
The file <<<pic1.jpg>>> will be available via a relative reference to the <<<images>>> directory from any page in your site.
* Configuring Reports
Maven has several reports that you can add to your web site to display the current state of the project.
These reports take the form of plugins, just like those used to build the project.
To add these reports to your site, you must add the plugins to a special <<<reporting>>> section in the POM. The
following example shows how to configure the standard project information reports that display information from the
POM in a friendly format:
-------------------
<project>
...
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
</plugin>
</plugins>
</reporting>
...
-------------------
If you have included the appropriate <<<${reports}>>> tag in your <<<site.xml>>> descriptor, then when you regenerate
the site those items will appear on the menu.
~~TODO: explain report sets
* Internationalisation
Internationalisation in Maven is very simple, as long as the reports you are using have that particular locale
defined.
To enable multiple locales, add configuration similar to the following to your POM:
-------------------
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<configuration>
<locales>en,fr</locales>
</configuration>
</plugin>
</plugins>
...
-------------------
This will generate both an English and a French version of the site. If <<<en>>> is your current locale, then it will
be generated at the root of the site, with a copy of the French translation of the site in the <<<fr/>>> subdirectory.
To add your own content for that translation instead of using the default, place a subdirectory with that locale
name in your site directory and create a new site descriptor with the locale in the file name. For example:
-------------------
+- src/
+- site/
+- apt/
| +- index.apt (Default version)
+- fr/
| +- apt/
| | +- index.apt (French version)
+- site.xml (Default site descriptor)
+- site_fr.xml (French site descriptor)
--------------------
With one site descriptor per language, the translated site(s) can evolve independently.
Using standard reports
There are many standard reports that are available by gleaning information from the POM. Currently
what is provided by default are:
* Dependencies Report
* Mailing Lists
* Continous Integration
* Source Repository
* Issue Tracking
* Project Team
* License
To find out more please refer to the
{{{http://maven.apache.org/plugins/maven-project-info-reports-plugin/howto.html}Project Info Reports Plug-in}}.

87
maven-site/src/site/apt/guides/mini/guide-using-ant.apt
View File

@ -1,87 +0,0 @@
------
Guide to using Ant with Maven
------
Jason van Zyl
------
12 October 2005
------
Guide to using Ant with Maven
The example above illustrates how to bind an ant script to a lifecycle phase. You can add a script to each lifecycle
phase, by duplicating the <execution/> section and specifying a new phase.
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>my-test-app</artifactId>
<groupId>my-test-group</groupId>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<configuration>
<tasks>
<!--
Place any ant task here. You can add anything
you can add between <target> and </target> in a
build.xml.
-->
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
+----+
So a concrete example would be something like the following:
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>my-test-app</artifactId>
<groupId>my-test-group</groupId>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<configuration>
<tasks>
<exec
dir="${basedir}"
executable="${basedir}/src/main/sh/do-something.sh"
failonerror="true">
<arg line="arg1 arg2 arg3 arg4" />
</exec>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
+----+

56
maven-site/src/site/apt/guides/mini/guide-using-extensions.apt
View File

@ -1,56 +0,0 @@
------
Guide to using Extensions
------
Jason van Zyl
------
12 October 2005
------
Using Extensions
Extensions are used to enable Wagon providers, used for the transport of artifact between repositories, and plug-ins
which provide lifecycle enhancements.
* Wagon providers
+----+
<project>
...
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-3</version>
</extension>
</extensions>
</build>
...
</project>
+----+
* Plug-ins which provide lifecycle enhancements
+----+
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-maven-plugin</artifactId>
<version>1.1-alpha-8-SNAPSHOT</version>
<extensions>true</extensions>
<configuration>
...
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+

38
maven-site/src/site/apt/guides/mini/guide-using-m1-repos-with-m2.apt
View File

@ -1,38 +0,0 @@
------
Guide to using Maven 1.x repositories with Maven 2.x
------
Jason van Zyl
------
12 October 2005
------
Guide to using Maven 1.x repositories with Maven 2.x
When you are migrating from Maven 1.x to Maven 2.x you will first be trying to convert your build and
to make this easier we have provided a way for you to use your existing Maven 1.x repository so that
you don't have to convert your repository before trying to migrate your projects. To use a Maven 1.x
repository with your Maven 2.x project you need to specify this in your POM as follows:
+----+
<project>
...
<repositories>
<repository>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>my-m1-repository</id>
<name>Maven 1.x Repository</name>
<url>http://repostory.mycompany.com/maven1</url>
<layout>legacy</layout>
</repository>
</repositories>
...
</project>
+----+
Enabling the snapshots is important as Maven 2.x makes a distinction between repositories that contain snapshots
and those that don't. In Maven 1.x there is no distinction, so setting snapshots to true will give you the Maven 1.x
style repository behaviour while using Maven 2.x.

66
maven-site/src/site/apt/guides/mini/guide-using-modello.apt
View File

@ -1,66 +0,0 @@
------
Guide to using Modello
------
Jason van Zyl
------
12 October 2005
------
Guide to using Modello
Modello is a tool for generating resources from a simple model. From a simple model you can generate
things like:
* Java sources
* XML serialization code for the model
* XML deserialization code for model
* Model documentation
* XSD
* JDO bindings
[]
A typical modello model looks like the following:
%{snippet|id=modello-model|url=http://svn.apache.org/repos/asf/maven/components/trunk/maven-archetype/maven-archetype-core/src/main/mdo/archetype.mdo}
To utilize Modello you would configure the <<<maven-modello-plugin>>> something like the following where you want
to generate the Java sources for the model, the xpp3 serialization code and the xpp3 deserialization code:
+----+
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<!-- Generate the xpp3 reader code -->
<goal>xpp3-reader</goal>
<!-- Generate the xpp3 writer code -->
<goal>xpp3-writer</goal>
<!-- Generate the Java sources for the model itself -->
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<model>src/main/mdo/descriptor.mdo</model>
<version>1.0.0</version>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
+----+

48
maven-site/src/site/apt/guides/mini/guide-webapp.apt
View File

@ -1,48 +0,0 @@
------
Guide to Webapps
------
Jason van Zyl
------
12 October 2005
------
+----+
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp
+----+
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-webapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<finalName>my-webapp</finalName>
</build>
</project>
+----+
Note the <packaging> element - this tells Maven to build as a WAR. Change into the webapp project's directory and try:
+----+
mvn clean:clean package
+----+
You'll see target/my-webapp.war is built, and that all the normal steps were executed.
Now you can modify this webapp project and turn it into anything you need!

9
maven-site/src/site/apt/guides/mini/index.apt
View File

@ -1,9 +0,0 @@
------
Maven Mini Guides
------
Jason van Zyl
------
12 October 2005
------
Maven Mini Guides

7
maven-site/src/site/apt/guides/mini/template.txt
View File

@ -1,7 +0,0 @@
------
Guide
------
Jason van Zyl
------
12 October 2005
------

117
maven-site/src/site/apt/guides/mktoc.sh
View File

@ -1,117 +0,0 @@
#!/bin/sh
toc=`pwd`/index.apt
find . -name '*~' -exec rm -rf {} \;
#
# Top matter
#
echo " ------ " > $toc
echo " Summary of Maven 2.x documentation " >> $toc
echo " ------ " >> $toc
echo " Jason van Zyl " >> $toc
echo " ------ " >> $toc
echo " 12 October 2005 " >> $toc
echo " ------ " >> $toc
echo >> $toc
echo "Documentation" >> $toc
echo >> $toc
#
# Getting started guide
#
echo "* Getting Started Guide" >> $toc
echo >> $toc
echo " * {{{getting-started/index.html}Getting Started Guide}}" >> $toc
#
# Mini Guides
#
echo >> $toc
echo "* Mini Guides" >> $toc
echo >> $toc
(
cd mini
for i in `ls -d guide-*`
do
if [ -d $i ]
then
(
cd $i
title=`grep "^ *Guide" ${i}.apt | sed 's/^ *//'`
i=`echo $i | sed 's/\.apt/\.html/'`
[ ! -z "$title" ] && echo " * {{{mini/$i/$i.html}$title}}" >> $toc && echo >> $toc
)
else
title=`grep "^ Guide" $i | sed 's/^ *//'`
i=`echo $i | sed 's/\.apt/\.html/'`
[ ! -z "$title" ] && echo " * {{{mini/$i}$title}}" >> $toc && echo >> $toc
fi
done
)
#
# Introductions
#
echo >> $toc
echo "* Introductory Material" >> $toc
echo >> $toc
(
cd introduction
for i in `ls introduction-*.apt`
do
title=`grep "^ Introduction" $i | sed 's/^ *//'`
i=`echo $i | sed 's/\.apt/\.html/'`
[ ! -z "$title" ] && echo " * {{{introduction/$i}$title}}" >> $toc && echo >> $toc
done
)
#
# Plugins
#
echo >> $toc
echo "* Plugin Guides" >> $toc
echo >> $toc
(
cd plugin
for i in `ls guide-*.apt`
do
title=`grep "^ Guide" $i | sed 's/^ *//'`
i=`echo $i | sed 's/\.apt/\.html/'`
[ ! -z "$title" ] && echo " * {{{plugin/$i}$title}}" >> $toc && echo >> $toc
done
)
#
# Developer Guides
#
echo >> $toc
echo "* Development Guides" >> $toc
echo >> $toc
(
cd development
for i in `ls guide-*.apt`
do
title=`grep "^ Guide" $i | sed 's/^ *//'`
i=`echo $i | sed 's/\.apt/\.html/'`
[ ! -z "$title" ] && echo " * {{{development/$i}$title}}" >> $toc && echo >> $toc
done
)
cat tail.txt >> $toc

397
maven-site/src/site/apt/guides/plugin/guide-java-plugin-development.apt
View File

@ -1,397 +0,0 @@
------
Guide to Developing Java Plugins
------
Bob Allison
------
12 October 2005
------
~~ Copyright 2001-2005 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.
Introduction
This guide is intended to assist users in developing Java plugins for
Maven 2.0.
* Your First Plugin
In this section we will build a simple plugin which takes no parameters
and simply displays a message on the screen when run. Along the way, we
will cover the basics of setting up a project to create a plugin, the
minimal contents of a Java mojo, and a couple ways to execute the mojo.
** Your First Mojo
At its simplest, a Java mojo consists simply of a single class. There is
no requirement for multiple classes like EJBs, although a plugin which
contains a number of similar mojos is likely to use an abstract
superclass for the mojos to consolidate code common to all mojos.
When processing the source tree to find mojos, the class
<<<org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor>>>
looks for classes with a "<<<goal>>>" annotation on the class. Any class
with this annotation are included in the plugin configuration file.
*** A Simple Mojo
Listed below is a simple mojo class which has no parameters. This is
about as simple as a mojo can be. After the listing is a description
of the various parts of the source.
+---+
package sample.plugin;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
/**
* @goal sayhi
* @description Says "Hi" to the user
*/
public class GreetingMojo extends AbstractMojo
{
public void execute() throws MojoExecutionException
{
getLog().info("Hello, world.");
}
}
+---+
* The class <<<org.apache.maven.plugin.AbstractMojo>>> provides most of the
infrastructure required to implement a mojo except for the
<<<execute>>> method.
* The comment lines starting with "<<<@goal>>>" and "<<<@description>>>"
are examples of annotations. These two annotations are required, but
there are a number of annotations which can be used to control how and
when the mojo is executed.
* The <<<execute>>> method can throw two exceptions:
* <<<org.apache.maven.plugin.MojoExecutionException>>> if an unexpected
problem occurs. Throwing this exception causes a "BUILD ERROR" message
to be displayed.
* <<<org.apache.maven.plugin.MojoFailureException>>> if an expected
problem (such as a compilation failure) occurs. Throwing this exception
causes a "BUILD FAILURE" message to be displayed.
* The <<<getLog>>> method (defined in <<<AbstractMojo>>>) returns a
log4j-like logger object which allows plugins to create messages at levels
of "debug", "info", "warn", and "error". This logger is the accepted means
to display information to the user.
** Project Definition
Once the mojos have been written for the plugin, it is time to
build the plugin. To do this properly, the project's descriptor
needs to have a number of settings set properly:
*------------------+----------------------------------------------------------+
|<<<groupId>>> |This is the group ID for the plugin, and should match the |
| |common prefix to the packages used by the mojos |
*------------------+----------------------------------------------------------+
|<<<artifactId>>> |This is the name of the plugin |
*------------------+----------------------------------------------------------+
|<<<version>>> |This is the version of the plugin |
*------------------+----------------------------------------------------------+
|<<<packaging>>> |This should be set to "<<<maven-plugin>>>" |
*------------------+----------------------------------------------------------+
|<<<dependencies>>>|A dependency must be declared to the Maven Plugin Tools |
| |API to resolve "<<<AbstractMojo>>>" and related classes |
*------------------+----------------------------------------------------------+
Listed below is a POM for a plugin which uses the simple sample mojo:
+----+
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>sample.plugin</groupId>
<artifactId>maven-hello-plugin</artifactId>
<packaging>maven-plugin</packaging>
<version>1.0-SNAPSHOT</version>
<name>Sample Parameter-less Maven Plugin</name>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
</project>
+----+
** Build Goals
There are a few goals which are defined with the Maven plugin
packaging as part of a standard build lifecycle:
*-------------+----------------------------------------------------+
|<<<compile>>>|Compiles the Java code for the plugin and builds the|
| |plugin descriptor |
*-------------+----------------------------------------------------+
|<<<test>>> |Runs the plugin's unit tests |
*-------------+----------------------------------------------------+
|<<<package>>>|Builds the plugin jar |
*-------------+----------------------------------------------------+
|<<<install>>>|Installs the plugin jar in the local repository |
*-------------+----------------------------------------------------+
|<<<deploy>>> |Deploys the plugin jar to the remote repository |
*-------------+----------------------------------------------------+
** Executing Your First Mojo
The most direct means of executing your new plugin is to specify the
plugin goal directly on the command line. To do this, you need to
specify a fully-qualified goal in the form of:
+----+
groupID:artifactID:version:goal
+----+
For example, to run the simple mojo in the sample plugin, you would enter
"<<<mvn sample.plugin:maven-hello-plugin:1.0-SNAPSHOT:sayhi>>>" on the
command line.
*** Shortening the Command Line
It is possible to shorten the amount of typing needed on the command
line. To do this, you need to install the plugin with the
<<<updateReleaseInfo>>> option set to true; for example:
+----+
mvn -DupdateReleaseInfo=true install
+----+
You also need to add your plugin's group ID to the list of group IDs
searched by default. To do this, you need to add the following to
your <<<settings.xml>>> file:
+----+
<pluginGroups>
<pluginGroup>sample.plugin</pluginGroup>
</pluginGroups>
+----+
At this point, you can run the mojo with "<<<mvn hello:sayhi>>>".
*** Attaching the Mojo to the Build Lifecycle
You can also configure your plugin to attach specific goals to a particular
phase of the build lifecycle. Here is an example:
+-----+
<build>
<plugins>
<plugin>
<groupId>sample.plugin</groupId>
<artifactId>maven-hello-plugin</artifactId>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>sayhi</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
+-----+
This causes the simple mojo to be executed whenever Java code is compiled.
For more information on binding a mojo to phases in the lifecycle, please
refer to the {{{/maven2/lifecycle.html}Build Lifecycle}} document.
* Parameters
It is unlikely that a mojo will be very useful without parameters.
Parameters provide a few very important functions:
* It provides hooks to allow the user to adjust the operation of the
plugin to suit their needs.
* It provides a means to easily extract the value of elements from
the POM without the need to navigate the objects.
** Defining Parameters Within a Mojo
Defining a parameter is as simple as creating an instance variable
in the mojo and adding the proper annotations. Listed below is an
example of a parameter for the simple mojo:
+-----+
/**
* The greeting to display.
* @parameter expression="Hello"
*/
private String greeting;
+-----+
The portion before the annotations is the description of the
parameter. The "<<<parameter>>>" annotation identifies
the variable as a mojo parameter. The "<<<expression>>>"
parameter defines the default value for the variable. This value can
include expressions which reference the project, such as
"<<<${project.version}>>>" (more can be found in the
"Parameter Expressions" document). The name of the variable is used
as the name of the parameter.
** Configuring Parameters in a Project
Configuring the parameter values for a plugin is done in a Maven 2
project within the <<<pom.xml>>> file as part of defining the
plugin in the project. An example of configuring a plugin:
+-----+
<plugin>
<groupId>sample.plugin</groupId>
<artifactId>maven-hello-plugin</artifactId>
<configuration>
<greeting>Welcome</greeting>
</configuration>
</plugin>
+-----+
In the configuration section, the element name
("<<<greeting>>>") is the parameter name and the contents of
the element ("<<<Welcome>>>") is the value to be assigned to
the parameter. More details can be found in the
{{{../mini/guide-configuring-plugins.html}Guide to Configuring Plugins}}.
** Parameter Types With One Value
Listed below are the various types of simple variables which can be used as
parameters in your mojos, along with any rules on how the values in the
POM are interpreted.
*** Boolean
This includes variables typed <<<boolean>>> and <<<Boolean>>>. When reading
the configuration, the text "<<<true>>>" causes the parameter to be set to
true and all other text causes the parameter to be set to false.
*** Fixed-Point Numbers
This includes variables typed <<<byte>>>, <<<Byte>>>, <<<int>>>,
<<<Integer>>>, <<<long>>>, <<<Long>>>, <<<short>>>, and <<<Short>>>. When
reading the configuration, the text in the XML file is converted to an
integer value using either <<<Integer.parseInt()>>> or the <<<valueOf()>>>
method of the appropriate class. This means that the strings must be valid
decimal integer values, consisting only of the digits 0 to 9 with an optional
<<<->>> in front for a negative value.
*** Floating-Point Numbers
This includes variables typed <<<double>>>, <<<Double>>>, <<<float>>>, and
<<<Float>>>. When reading the configuration, the text in the XML file is
converted to binary form using the <<<valueOf()>>> method for the appropriate
class. This means that the strings can take on any format specified in
section 3.10.2 of the Java Language Specification. Some samples of valid
values are <<<1.0>>> and <<<6.02E+23>>>.
*** Dates
This includes variables typed <<<Date>>>. When reading the configuration,
the text in the XML file is converted using one of the following date
formats: "<<<yyyy-MM-dd HH:mm:ss.S a>>>" (a sample date is "2005-10-06
2:22:55.1 PM") or "<<<yyyy-MM-dd HH:mm:ssa>>>" (a sample date is "2005-10-06
2:22:55PM"). Note that parsing is done using <<<DateFormat.parse()>>> which
allows some leniency in formatting. If the method can parse a date and time
out of what is specified it will do so even if it doesn't exactly match the
patterns above.
*** Files and Directories
This includes variables typed <<<File>>>. When reading the configuration,
the text in the XML file is used as the path to the desired file or
directory. If the path is relative (does not start with <<</>>> or a drive
letter like <<<C:>>>), the path is relative to the directory containing
the POM.
*** URLs
This includes variables typed <<<URL>>>. When reading the configuration, the
text in the XML file is used as the URL. The format must follow the RFC 2396
guidelines, and looks like any web browser URL
(<<<scheme://host:port/path/to/file>>>). No restrictions are placed on the
content of any of the parts of the URL while converting the URL.
*** Plain Text
This includes variables typed <<<char>>>, <<<Character>>>, <<<StringBuffer>>>,
and <<<String>>>. When reading the configuration, the text in the XML file is
used as the value to be assigned to the parameter. For <<<char>>> and
<<<Character>>> parameters, only the first character of the text is used.
** Parameter Types With Multiple Values
Listed below are the various types of composite objects which can be used as
parameters in your mojos, along with any rules on how the values in the
POM are interpreted. In general, the class of the object created to hold the
parameter value (as well as the class for each element within the parameter
value) is determined as follows (the first step which yields a valid class
is used):
[[1]] If the XML contains an <<<implementation>>> hint, that is used
[[2]] If the XML tag contains a <<<.>>>, try that as a class name
[[3]] Try the XML tag as a class in the same package as the object being
configured
[[4]] For arrays, use the class of the array (for example, use <<<String>>>
for a <<<String[]>>> parameter); for collections and maps, use the
class specified in the mojo configuration for the collection or map;
use <<<String>>> for entries in a collection and values in a map
Once the type for the element is defined, the text in the XML file is
converted to the appropriate type of object
*** Arrays
Array type parameters are configured by specifying the parameter multiple
times (for example, "<<< <param>value1</param> <param>value2</param> >>>").
*** Collections
This category covers any class which implements <<<java.util.Collection>>>
such as <<<ArrayList>>> or <<<HashSet>>>. These parameters are configured by
specifying the parameter multiple times just like an array.
*** Maps
This category covers any class which implements <<<java.util.Map>>>
such as <<<HashMap>>> but does <<not>> implement <<<java.util.Properties>>>.
These parameters are configured by including XML tags in the form
<<< <key>value</key> >>> in the parameter configuration.
*** Properties
This category covers any map which implements <<<java.util.Properties>>>.
These parameters are configured by including XML tags in the form
<<< <key>value</key> >>> in the parameter configuration.
*** Other Object Classes
This category covers any class which does not implement <<<java.util.Map>>>,
<<<java.util.Collection>>>, or <<<java.util.Dictionary>>>.
* Resources
[[1]] {{{../../developers/mojo-api-specification.html}Mojo API specification}}

6
maven-site/src/site/apt/guides/plugin/notes.txt
View File

@ -1,6 +0,0 @@
Packaging plugins are required to call project.getArtifact().setFile(
fileYouGenerated ) to properly work in the reactor.
o configuration at
plugin-level
execution-level

122
maven-site/src/site/apt/guides/suggestions/non-standard-directories.txt
View File

@ -1,122 +0,0 @@
I posted these instructions a little while ago on how to use Maven 2
with a non
standard single source tree rather than individual modules. Might be
useful for existing
projects without the budget or inclination to move over to the
standard structure.
Or maybe this technique would encourage a project to get an early
idea of how
maven would work with their code before actually migrating to the
standard layout,
with ilttle risk.
AW
-------------------------------------
I believe with just a few pom.xml tweaks I've managed to get
something of a single source project to work with maven. It could be
that a few bug fixes since Maven alpha have helped since the last
time I tried but here's what I did.
1. Designed a bogus project consisting of a gui artifact that depends
on a util artifact each with a single class: Main.java and Util.java
respectively. Additionally the gui component uses a resource file
called gui.properties. I then arranged this project into the
following directory structure:
com
--------acme [pom.xml]
----------------util [Util.java, pom.xml]
----------------gui [Main.java, pom.xml]
------------------------resources [gui.properties]
2. The gui and util poms only declare the acme/pom as a parent and
don't even have their own build section. The acme/pom.xml parent
contains the necessary tweaks that the child poms inherit, namely
inside the build section:
acme/pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.acme</groupId>
<artifactId>app</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>Acme Application</name>
<modules>
<module>util</module>
<module>gui</module>
</modules>
<build>
<sourceDirectory>.</sourceDirectory>
<resources>
<resource>
<directory>resources</directory>
</resource>
</resources>
</build>
</project>
~
In other words the java files and resources/ directory are to be
found in the same directory as the pom.xml file for any given
artifact project.
3. I ran the install phase as follows:
> cd com/acme
> mvn install
which caused the target directories to be generated also at the same
level as each pom - for example com/acme/util/target and com/acme/gui/
target.
4. I examined the jar files in each target directory for example "jar
tvf com/acme/gui/target/gui-1.0-SNAPSHOT.jar" resulted in:
META-INF/
META-INF/MANIFEST.MF
META-INF/maven/
META-INF/maven/com.acme/
META-INF/maven/com.acme/gui/
META-INF/maven/com.acme/gui/pom.xml
com/
com/acme/
com/acme/gui/
com/acme/gui/Main.class
gui.properties
META-INF/maven/com.acme/gui/pom.properties
which looks fine. I also ran "mvn site:site" as a random goal and that
seemed to work too, ie a target/site directory was created with all
the files correctly generated underneath.
***************************
My conclusions are that it seems too easy so far and that I've missed
a howler - if somebody could point it out?? Also in the acme/pom.xml
file I would still need to add the equivalent test tags, eg
<testResourceDirectory>.
Would it be possible to encapsulate these tweaks and any others that
become apparent into a plugin so I could do something like the
following in any application (root) pom:
<build>
<plugins>
<plugin>
<groupId>com.maven.plugins</groupId>
<artifactId>project-structure</artifactId>
<version>1.0</version>
<configuration>
<method>one-tree</method>
</configuration>
</plugin>
</plugins>
</build>
Thanks
AW

20
maven-site/src/site/apt/guides/tail.txt
View File

@ -1,20 +0,0 @@
* Reference
* {{{../maven-model/maven.html}Project Descriptor}}
* {{{../maven-settings/settings.html}Settings Descriptor}}
* {{{../plugins/index.html}Available Plug-ins}}
* {{{../developers/mojo-api-specification.html}Mojo API}}
* {{{../ant-tasks.html}Ant Tasks}}
* {{{../glossary.html}Glossary}}
* {{{../maven-conventions.html}Maven Conventions}}
* {{{../articles.html}Articles}}
[]

52
maven-site/src/site/apt/maven-conventions.apt
View File

@ -1,52 +0,0 @@
------
Maven Features
------
Jason van Zyl
Brett Porter
------
12 October 2005
------
Maven Conventions
This document defines some conventions that Maven recommends projects adopt. This is especially important if
you intend to distribute your project publicly.
Artifact Naming
This section outlines the naming conventions used in the Maven
project object model (POM). This document is an attempt to try and
unify the many various ways projects name the artifacts that they
publish for general consumption by the Java developer community (regardless of whether they are using Maven).
The first thing you will do when creating a project is to select a group ID and an artifact ID.
If you are building a project to be part of a larger product that is already using Maven, you should attempt to
follow any patterns already established by other projects for consistency.
These identifiers should be comprised of <i>lowercase</i> letters, digits, and hyphens only.
In general you should select a group ID that describes the entire product, and artifact IDs that are the
basis of filenames for each item you distribute. The artifact ID may or may not overlap the group ID.
For example:
+----+
maven : maven-core
maven : wagon-api
+----+
As previously mentioned, the artifact ID should be the basis of the filename for the project, as by default
Maven will use that and the version to assemble the filename. Having the version as part of the filename is
strongly recommended to ensure that the version can be determined at a glance without having to check a possibly
non-existant manifest, or compare file sizes with the official releases.
Following these guidelines are particularly encouraged when distributing via the Maven Repository, to ensure
that it can easily fit alongside other projects and reduce the risk of conflicts and confusion.
Directory Structure
Maven encourages a common directory structure for a project. For more information on this please refer
to our {{{introduction/introduction-to-the-standard-directory-layout.html}Introduction to the standard
directory structure}}.

61
maven-site/src/site/apt/maven-features.apt
View File

@ -1,61 +0,0 @@
------
Maven Features
------
Jason van Zyl
------
12 October 2005
------
Feature Summary
The following are the key features of Maven in a nutshell:
* Simple project setup that follows best practices - get a new project or module started in seconds
* Consistent usage across all projects means no ramp up time for new developers coming onto a project
* Superior dependency management including automatic updating, dependency closures (also known as transitive dependencies)
* Able to easily work with multiple projects at a time
* A large and growing repository of libraries and metadata to use out of the box, and arrangements in place with the largest Open Source projects for
real-time availability of their latest releases
* Extensible, with the ability to easily write plugins in Java or other scripting languages
* Instant access to new features with little or no extra configuration
* Ant tasks for dependency management and deployment outside of Maven
* Model based builds:
Maven is able to build any number of projects into predefined output types
such as a JAR, WAR, or distribution based on metadata about the project, without
any need to do any scripting in most cases.
* Coherent site of project information:
Using the same metadata as for the build process, Maven is able to generate a
web site or PDF including any documentation you care to add, and adds to that
standard reports about the state of development of the project.
Examples of this information can be seen at the bottom of the left-hand navigation of
this site under the "Project Information" and "Project Reports" submenus.
* Release management and distribution publication:
Without much additional configuration, Maven will integrate with your source control
system such as CVS and manage the release of a project based on a certain tag.
It can also publish this to a distribution location for use by other projects.
Maven is able to publish individual outputs such as a JAR, an archive including other
dependencies and documentation, or as a source distribution.
* Dependency management:
Maven encourages the use of a central repository of JARs and other dependencies. Maven
comes with a mechanism that your project's clients can use to
download any JARs required for building your project from a
central JAR repository much like Perl's CPAN. This allows users
of Maven to reuse JARs across projects and encourages communication
between projects to ensure backward compatibility issues are
dealt with. We are collaborating with the folks at {{{http://www.ibiblio.org}Ibiblio}} who have graciously
allowed the central repository to live on their servers.
[]
~~ this needs to be greatly expanded and is too detailed here ... jvz

21
maven-site/src/site/apt/powered-by-m2.apt
View File

@ -1,21 +0,0 @@
-----
Powered by Maven 2.x
-----
Jason van Zyl
-----
12 October 2005
-----
Powered by Maven 2.x
* {{{http://maven.apache.org}Maven}}
* {{{http://plexus.codehaus.org}Plexus}}
* {{{http://maven.apache.org/continuum}Continuum}}
* {{{http://openejb.codehaus.org}OpenEJB}}
* {{{http://www.activemq.org}ActiveMQ}}
* {{{http://gforge.public.thoughtworks.org/projects/dbfixture/}DbFixture}}

66
maven-site/src/site/apt/proposals/plugin-tool-refactoring.apt
View File

@ -1,66 +0,0 @@
---
Refactoring Proposal: Accommodating Generators for Multiple Plugin Types
---
John Casey
---
09-Feb-2005
---
Abstract
Propose changing the structure of maven-plugin-tools to accommodate multiple
plugin languages and their needs during the descriptor, etc. generation
process. Details below.
Refactor Details
[[1]] Move the existing project (maven-plugin-tools) to
<<<maven-plugin-tools/maven-plugin-tools-java>>>. Adjust dependencies on
this library accordingly within maven-components.
[[2]] Create other plugin-tools libraries to accommodate generation needs for
other languages, as needed.
The first use-case of this is the descriptor generator for
marmalade-based mojos. Since we don't want the "normal" plugin tools
to depend on marmalade, etc. we need to make the concept of plugin-tools
abstract, and provide a concrete implementation for the java language,
as well as marmalade.
[[3]] Create plugin-tools root pom if needed for inheriting common values...
I don't anticipate needing this initially, but if there is some question
of consistency wrt this, we can certainly provide one.
[[4]] Create common API for use in all generator libraries. This will define
the interface for a mojo descriptor (and other) generator. Therefore, it
will require splitting the responsibility of the old PluginDescriptorGenerator
from what is to be the maven-plugin-tools-java library into two pieces:
- Section covered by the AbstractGenerator code will be the complete new
generator for java. It will probably be further abstracted as an
interface for other language implementations to follow, and then itself
made into a concrete, instantiable implementation. The interface will
define the new Reader/Source role of this class, used to produce
MojoDescriptor instances from the project source files.
- Specifics handled by the PluginDescriptorGenerator (and others) will
be factored into the common API, and generalized as a Writer/Sink role,
used to generate one or more derivative files from the MojoDescriptors
discovered by the set of Reader/Sources.
Once this split is accomplished, an additional class will be created to
act as a managing component for all generators registered in plexus. It
will require a mapping of Source-language->Source-instance where each
Source is a plexus component. Unless/until we have some smarter way of
specifying a plugin language as a means of singling out one Source for
the project, this manager component will simply iterate through all
Source instances, collect the MojoDescriptors from each, wrap them in
MavenMojoDescriptors with the component-factory specified == to the
Source language, and aggregate the resulting MavenMojoDescriptors in
some Collection.
Finally, the Source manager returns the aggregated result of all Sources
to the calling mojo. The mojo will be responsible for digesting the
MavenMojoDescriptors into the requisite files.

59
maven-site/src/site/apt/release-notes.apt
View File

@ -1,59 +0,0 @@
------
Release Notes - Maven 2.0
------
Brett Porter
------
18 October 2005
------
The Apache Maven team would like to announce the release of Maven 2.0.
Maven 2.0 is available for download from {{http://maven.apache.org/maven2/download.html}}
Maven is a software project management and comprehension tool. Based on the concept of a project object model
(POM), Maven can manage a project's build, reporting and documentation from a central place.
Maven 2.0 is a rewrite of the popular Maven application to achieve a number of new goals, and to provide a stable
basis for future development.
This release includes the following new features and changes since Maven 1.0:
* Significantly faster and smaller than previous releases.
* Improved dependency management including dependency closures (transitive dependencies), version ranges, automatic
build numbering, and automatic updating on a configurable interval.
* Defined build lifecycle. Any type of project can be built using standard commands such as compile, test and
install.
* Improved reactor operation. Built in support for multiple projects and without the need to perform a full install
cycle to compile all projects. Includes support for project aggregation.
* Improved plugin architecture, with plugins that can be written in Java and scripting languages such as Beanshell.
* Unified project definition. All information required to build is contained in a single POM, including project
information, dependencies and plugin configuration.
* Improved repository support, including separated snapshot repositories, a new more managable layout and per-project
definitions of new repositories.
* New site management tools that support multiple input and output formats. New input formats include wiki-like
APT format, docbook while continuing to support traditional Maven XDoc and FAQ format.
* Reporting API for producing project information and reports in a standard way.
This release is considered stable with a feature set that encompasses and supersedes Maven 1.0.
This core release is independent of the plugins available. Further releases of plugins will be made separately.
See {{{http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Matrix} Maven Plugin Matrix}} for more information.
We hope you enjoy using Maven! If you have any questions, please consult:
* the web site: {{http://maven.apache.org/maven2/}}
* the maven-user mailing list: {{http://maven.apache.org/mail-lists.html}}
For news and information, see:
* Maven Blogs: {{http://www.mavenblogs.com/}}

135
maven-site/src/site/apt/what-is-maven.apt
View File

@ -1,135 +0,0 @@
------
What is Maven?
------
Jason van Zyl
------
12 October 2005
------
Introduction
Maven was originally started as an attempt to simplify the build
processes in the Jakarta Turbine project. There were several
projects each with their own Ant build files that were all slightly
different and JARs were checked into CVS. We wanted a standard way to
build the projects, a clear definition of what the project consisted
of, an easy way to publish project information and a way to share JARs
across several projects.
What resulted is a tool that can now be used for building and managing
any Java-based project. We hope that we have created something that
will make the day-to-day work of Java developers easier and generally
help with the comprehension of any Java-based project.
Maven's Objectives
Maven's primary goal is to allow a developer to comprehend the
complete state of a development effort in the shortest period of
time. In order to attain this goal there are several areas of concern
that Maven attempts to deal with:
* Making the build process easy
* Providing a uniform build system
* Providing quality project information
* Providing guidelines for best practices development
* Allowing transparent migration to new features
* Making the build process easy
While using Maven doesn't eliminate the need to know about the
underlying mechanisms, Maven does provide a lot of shielding
from the details.
* Providing a uniform build system
Maven allows a project to build using its project object model (POM) and
a set of plugins that are shared by all projects using
Maven, providing a uniform build system. Once you familiarize yourself
with how one Maven project builds you automatically know how all Maven
projects build saving you immense amounts of time when trying to
navigate many projects.
* Providing quality project information
Maven provides plenty of useful project information that is in
part taken from your POM and in part generated from your project's
sources. For example, Maven can provide:
* Change log document created directly from source control
* Cross referenced sources
* Mailing lists
* Dependency list
* Unit test reports including coverage
[]
As Maven improves the information set provided will improve, all of
which will be transparent to users of Maven.
Other products can also provide Maven plugins to allow their set of
project information alongside some of the standard information given by
Maven, all still based from the POM.
* Providing guidelines for best practices development
Maven aims to gather current principles for best practices development, and
make it easy to guide a project in that direction.
For example, specification, execution, and reporting of unit tests are part of
the normal build cycle using Maven.
Current unit testing best practices were used as guidelines:
* Keeping your test source code in a separate, but parallel source tree
* Using test case naming conventions to locate and execute tests
* Have test cases setup their environment and don't rely on customizing the build for test preparation.
[]
Maven also aims to assist in project workflow such as release management and
issue tracking.
Maven also suggests some guidelines on how to layout your project's directory structure
so that once you learn the layout you can easily navigate any other project that uses
Maven and the same defaults.
* Allowing transparent migration to new features
Maven provides an easy way for Maven clients to update their installations
so that they can take advantage of any changes that been made to
Maven itself.
Installation of new or updated plugins from third parties or Maven itself has
been made trivial for this reason.
What is Maven Not?
You may have heard some of the following things about Maven:
* Maven is a site and documentation tool
* Maven extends Ant to let you download dependencies
* Maven is a set of reusable Ant scriptlets
[]
While Maven does these things, as you can read above in the "What is Maven?" section,
these are not the only features Maven has, and it's objectives are quite different.
Maven does encourage best practices, but we realise that some projects may not fit with
these ideals for historical reasons. While Maven is designed to be flexible, to an extent, in these
situations and to the needs of different projects, it can not cater to every situation without making
compromises to the integrity of its objectives.
If you decide to use Maven, and have an unusual build structure that you cannot reorganise, you may
have to forgo some features or the use of Maven altogether.

32
maven-site/src/site/apt/where-is-it.apt
View File

@ -1,32 +0,0 @@
------
Where is it?
------
Jason van Zyl
------
12 October 2005
------
Where is it?
As we have moved toward the release of Maven 2.0 we have built up a vast
store of knowledge that is sometimes hard to communicate with users because
there is just so much to communicate and limits of resources. Here are a few
quick references in an attempt to help in the short term. Obviously if users
cannot find resources the navigation and/or content needs further
organization. Hope this helps for now.
* POM references
* {{{/maven-model/maven.html}Project Descriptor}}
* Settings references
* {{{../maven-settings/settings.html}Settings Descriptor}}
* Mailing list archives
* {{{http://www.nabble.com/Maven---Users-f178.html}Nabble for users}}
* {{{http://www.nabble.com/Maven---Dev-f179.html}Nabble for developers}}
* {{{http://mail-archives.apache.org/mod_mbox/maven-users/}Apache Archives}}

113
maven-site/src/site/fml/about.fml
View File

@ -1,113 +0,0 @@
<?xml version="1.0"?>
<faqs title="About Maven 2.0">
<part id="about">
<faq id="m2-goals">
<question>Tell me about the goals of Maven 2.0</question>
<answer>
<p>
You've seen
<a href="#what-is-maven">above</a>
the goals that Maven aims to achieve, however there have also
been questions about why Maven 2.0 is rewritten from the successful Maven 1.0. In summary, the main goals of
the new Maven 2.0 architecture are:
</p>
<ul>
<li>To be simple to use - it should be more obvious and consistent about how things are working</li>
<li>Fast - a new architecture and smaller memory footprint make it as fast as possible</li>
<li>To be able to implement the features demanded that were not possible under the Maven 1.0 architecture</li>
</ul>
<p>
Unfortunately, to reach these goals we've had to sacrifice backwards compatibility. Instead of
making many small incremental changes that would break compatibility often over time, we decided to build on a
new, solid base that can be reliable for the future, and also to maintain the existing Maven 1.x product to
ensure that existing users are not left out in the cold.
</p>
</answer>
</faq>
<faq id="get-involved">
<question>Can I get involved?</question>
<answer>
<p>
The Maven project welcomes anyone that wishes to contribute to do so by providing patches to the source code,
participating in design discussions, or to help out on the users mailing list by answering questions.
</p>
<p>
Frequent contributors recognised by existing committers to the project may be asked if they would like to
join the project.
</p>
<p>
For instructions on checking out and building Maven 2.0, see
<a href="/maven2/developers/building.html">Building Maven 2.0</a>
.
</p>
<p>
For more information, please see
<a href="http://maven.apache.org/contributing/help.html">How to Help</a>
.
</p>
</answer>
</faq>
<faq id="scripting-languages">
<question>What plugin languages will Maven 2.0 support? What about [insert language here]?</question>
<answer>
<p>
As of the current release, Maven supports pure Java and Beanshell. Java is the preferred
language for it's familiarity and speed.
</p>
<p>
We get asked a lot whether Maven 2.0 will support other languages, in particular Groovy.
We will allow the use of Groovy - and virtually any other scripting
language (if there is demand) or someone can commit a small amount of time to implementing a
factory for it.
</p>
<p>
We would recommend waiting for Groovy to have a 1.0 release so the API
(and language!) is stable. What we will not be doing is actively
supporting it (in terms of answering questions about how to use it)
like we currently do for Jelly in Maven 1.x.
</p>
<p>
Beanshell is more mature, and we want a language that users will find
answers for when they look, and that when they find bugs, it is
clearly defined where they actually are.
</p>
<p>
We may consider emphasising a different language if there are compelling technical reasons
for doing so - if you have a suggestion, feel free to contact the development list.
</p>
</answer>
</faq>
<faq id="get-help">
<question>Where do I get help with Maven 2.0?</question>
<answer>
<p>
Help for both Maven 1.0 and Maven 2.0 can be obtained by subscribing and posting to the
<a href="http://maven.apache.org/mail-lists.html">Maven Users List</a>
. If you are posting about Maven 2.0,
please make that clear in your email.
</p>
<p>
You can also join us on IRC at
<code>irc.codehaus.org</code>
on
<code>#maven</code>
. This is available both
over
<a href="irc://irc.codehaus.org/#maven">IRC</a>
and
<a href="http://irc.codehaus.org/">HTTP</a>
for those behind firewalls (enter
<code>#maven</code>
in the
<i>Channel</i>
box).
</p>
</answer>
</faq>
</part>
</faqs>

172
maven-site/src/site/fml/general.fml
View File

@ -1,172 +0,0 @@
<?xml version="1.0"?>
<faqs title="Frequently Asked Technical Questions">
<part id="faq">
<faq id="scope-provided">
<question>How do I prevent including JARs in WEB-INF/lib? I need a "compile only" scope!</question>
<answer>
<p>
The scope you should use for this is
<code>provided</code>. This indicates to Maven that the dependency will be
provided at run time by its container or the JDK, for example.
</p>
<p>
Dependencies with this scope will not be passed on transitively, nor will they be bundled in an package such
as
a WAR, or included in the runtime classpath.
</p>
</answer>
</faq>
<faq id="available-plugins">
<question>How do I list available plugins?</question>
<answer>
<p>
To see a list of available plugins, browse the Maven 2 plugin repository
at
<a href="http://www.ibiblio.org/maven2/plugins/">http://www.ibiblio.org/maven2/plugins/</a>.
Plugins are organized according to a directory structure that resembles
the standard Java package naming convention. To see a list of available
plugins from the Maven project look in the
<a href="http://www.ibiblio.org/maven2/plugins/org/apache/maven/plugins/">org/apache/maven subfolder</a>
of this directory.
</p>
</answer>
</faq>
<faq id="using-ant-tasks">
<question>How can I use Ant tasks in Maven 2?</question>
<answer>
<p>
There are currently 2 alternatives:
</p>
<ul>
<li>
For use in a plugin written in Java, Beanshell or other Java-like scripting language, you can construct
the Ant tasks using the
<a href="http://ant.apache.org/manual/antexternal.html">instructions given in the Ant
documentation</a>
</li>
<li>
If you have very small amounts of Ant script specific to your project, you can use the
<a href="http://www.neonics.com/projects/maven-antrun-plugin/">AntRun plugin</a>.
</li>
</ul>
</answer>
</faq>
<faq id="Compiling-J2SE-5">
<question>How do I set up Maven so it will compile with a target and source JVM of my choice?</question>
<answer>
<p>
You must configure the source and target parameters in your pom. For example, to set the source and target JVM
to 1.5, you should have in your pom :
</p>
<source><![CDATA[
<build>
...
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
...
</build>
]]></source>
</answer>
</faq>
<faq id="dir-struct">
<question>Is it possible to create my own directory structure?</question>
<answer>
<p>
Absolutely yes!
</p>
<p>
By configuring &amp;lt;sourceDirectory&amp;gt;, &amp;lt;resources&amp;gt; and other elements of
the &amp;lt;build&amp;gt; section.
</p>
<p>
In addition, you may need to change the plugin configuration if you are
not using plugin defaults for their files/directories.
</p>
</answer>
</faq>
<faq id="m2-source-code">
<question>Where is the source code? I couldn't seem to find a link anywhere on the Maven2 site.</question>
<answer>
<p>
The source code can be found in subversion: <a href="http://svn.apache.org/repos/asf/maven/components/trunk">http://svn.apache.org/repos/asf/maven/components/trunk</a>.
</p>
<p>
For more information, see <a href="developers/building.html">Building Maven 2.0</a>.
</p>
</answer>
</faq>
<faq id="proxy-needed">
<question>Maven can't seem to download the dependencies. Is my installation correct?</question>
<answer>
<p>
You most probably need to configure Maven to use a proxy. Please see the information on
<a href="configuration.html">configuring settings.xml</a> for information on how to configure your proxy
for Maven.
</p>
</answer>
</faq>
<faq id="importing-jars">
<question>I have a jar that I want to put into my local repository. How can I copy it in?</question>
<answer>
<p>
If you understand the layout of the maven repository, you can copy the jar directly into where it
is meant to go. Maven will find this file next time it is run.
</p>
<p>
If you are not confident about the layout of the maven repository, then you can
adapt the following command to load in your jar file, all on one line.
</p>
<source><![CDATA[
m2 install:install-file
-Dfile=<path-to-file>
-DgroupId=<group-id>
-DartifactId=<artifact-id>
-Dversion=<version>
-Dpackaging=<packaging>
Where: <path-to-file> the path to the file to load
<group-id> the group that the file should be registered under
<artifact-id> the artifact name for the file
<version> the version of the file
<packaging> the packaging of the file e.g. jar
]]></source>
<p>
This should load in the file into the maven repository, renaming it as needed.
</p>
</answer>
</faq>
<faq id="unsubscribing-from-mailing-lists">
<question>How do I unsubscribe from Maven mailing lists?</question>
<answer>
To unsubscribe from a Maven mailing list you simply send a message to
\[mailing-list\]-unsubscribe@maven.apache.org. So, if you have
subscribed to users@maven.apache.org then you would send a message
to users-unsubscribe@maven.apache.org in order to get off the list.
People tend to have problems when they subscribe with one address and
attempt to unsubscribe with another. So make sure that you are using the
same address when unsubscribing that you used to subscribe before
asking for help. If you find you still cannot get off a list then
send a message to \[mailing-list\]-help@maven.apache.org. These
instructions are also appended to every message sent out on
a maven mailing list ...
</answer>
</faq>
</part>
</faqs>

181
maven-site/src/site/fml/maven1.fml
View File

@ -1,181 +0,0 @@
<?xml version="1.0"?>
<faqs title="Information for Maven 1.0 Users">
<part id="maven1">
<faq id="changed">
<question>What's Changed?</question>
<answer>
<p>
Maven 2.0 will feel very different to a Maven 1.0 user - and perhaps a little strange. But it is a lot simpler
to work with and closer to how Maven was always meant to be! The key changes from Maven 1.0 are:
</p>
<ul>
<li>
<i>Faster and smaller</i>
- The Maven core no longer uses Ant, Jelly or Xerces making it much smaller, have
fewer dependencies, and is perfect for embedding in other tools.
</li>
<li>
<i>Defined build lifecycle</i>
- No more
<code>prereqs</code>
,
<code>preGoals</code>
and
<code>postGoals</code>
.
The build is a series of well defined phases. This also means that the normal goal names are not used -
<code>compile</code>
,
<code>test</code>
and
<code>install</code>
work for any project type.
</li>
<li>
<i>Built-in multiple project handling</i>
- Use the same goals on a set of projects, and aggregate the
results.
</li>
<li>
<i>Improved
<code>SNAPSHOT</code>
handling
</i>
- Snapshots are now checked for updates only once per day by
default - though can be configured to be once per build, on a particular interval, or never. A command line
option can force a check - making it more like updating from an SCM.
</li>
<li>
<i>No more properties files</i>
- All plugins are now configured from the POM (which is now called
<code>pom.xml</code>
).
</li>
<li>
<i>No more
<code>maven.xml</code>
</i>
- Plugins are now easier to build and integrate, and are the only way
to script your builds. (Note that additions may later be made to the POM to allow simple things that
scripting
was used for, such as goal aliasing).
</li>
<li>
<i>No more Jelly</i>
- Plugins are primarily written in Java, though there are providers for other scripting languages.
</li>
<li>
<i>Improved repository layout</i>
- Maven 2.0 supports both the existing layout, and an improved repository
layout that has deeper, partitioned structure making it easier to browse.
</li>
</ul>
</answer>
</faq>
<faq id="m1-or-m2">
<question>Should I use Maven 2.0, or Maven 1.0?</question>
<answer>
<p>
The answer depends very much on on your circumstances, and in particular whether you are new to Maven or not.
</p>
<p>
The simple answer is that we hope you'll try Maven 2.0, and use it if it works for you. However, it is a beta
release, so you can expect some unexpected bugs.
We'd hate for your first experience with Maven 2.0 to be a bad one - so if you are embarking on a big,
complicated
or mission critical project - we still recommend Maven 1.0.2 as the latest stable release.
</p>
<p>
If you are already using Maven 1.0 - feel free to try out Maven 2.0, but it may be better to remain on an
existing
version that is working for you until you need the new features and it covers all of your needs.
</p>
<p>
If you do use Maven 1.0, and would like to upgrade in the future, you should carefully consider following some
of the
<a href="http://maven.apache.org/using/bestpractices.html">Best Practices</a>
listed. These will make
your project a lot easier to migrate in the future.
</p>
<p>
The following are the known limitations in the current Maven 2.0 release:
</p>
<ul>
<li>
<i>Error handling</i>
- there are occasions where Maven 2.0 will drop out with a long stack trace
when an error has occurred. If a specific trace is not providing enough information to find out what went
wrong, please post the message to JIRA.
</li>
<li>
<i>Availability of other plugins</i>
- While most of the core Maven 1.x plugins have been converted,
there are still some not available, or not with the same level of features or documentation. In
addition, several 3rd party plugins may not be available. Maven 2.0 cannot execute Maven 1.0 plugins.
</li>
</ul>
</answer>
</faq>
<faq id="m1-future">
<question>What will happen to Maven 1.0?</question>
<answer>
<p>
Maven 1.0.2 continues to work, and a 1.1 release is still under way. While significant new features will not
be added to the Maven 1.0 core (such as transitive dependencies), bugfixes and support continue and the
repository is still available. Features from Maven 2.0 may be included in Maven 1.1 where possible.
</p>
<p>
An end-of-life for Maven 1.0.2 will be announced when this is decided - but there are currently no plans for
this to happen.
</p>
</answer>
</faq>
<faq id="m1-plugins">
<question>Will my Maven 1.0 plugins be supported?</question>
<answer>
<p>
Not directly.
</p>
<p>
We recommend building your Jelly plugins as thin wrappers around Java beans that do not use Maven 1.0 API's,
which will allow easy migration to Maven 2.0.
</p>
</answer>
</faq>
<faq id="m1-maven-xml">
<question>How do I write custom scripts without a
<code>maven.xml</code>
file?
</question>
<answer>
<p>Taken from
<a href="http://mail-archives.apache.org/mod_mbox/maven-users/200504.mbox/%3c1113788711.5625.30.camel@172.16.1.36%3e">
this post to the Maven User's List</a>
:
</p>
<blockquote>
Everything in m2 is a plugin so for doing any sort of custom work like
that you will need to make a plugin. This 1) greatly reduces the
complexity within m2 because we only deal with proper plugins. The
maven.xml file in m1 was a psuedo plugin essentially and greatly
complicated the internals and 2) it promotes the sharing of your work
right from the get go. To start with you'll probably write a plugin that
is only applicable to your specific requirements, or your team's work,
but you'll see people asking for some functionality and you'll go "hey,
I have something like that!" and hopefully people who have concrete
solutions will generalize their solutions so they can be shared with
others. That's what we're trying to encourage.
</blockquote>
<blockquote>
We estimate that there's a lot of work bound up in project's maven.xml
that is not being shared and we'd like to try and change that. We plan
to make it dead simple to share plugins and hopefully people can use
other project's plugins as a start for a plugin that they may need
themselves.
</blockquote>
</answer>
</faq>
</part>
</faqs>

96
maven-site/src/site/fml/project-faq.fml
View File

@ -1,96 +0,0 @@
<?xml version="1.0"?>
<faqs title="Frequently Asked Questions About Project Metadata">
<part id="faq">
<faq id="why-care">
<question>Why do I care?</question>
<answer>
<p>
If you're a user of Maven then you are familiar with the Project Object Model (POM) which is the basic unit of
work in Maven. Maven is a project-centric tool and so we attempt to capture the essence of a project in the
POM. This includes things like what your project is, where the project lives, where you can find the sources
for project, who the developers are on the project and how you can get hold of them, what you need to build
the project, the way your project will be built, what form your project will be distributed in, and where it
will be distributed from.
</p>
<p>
But why would a project not using Maven care?
</p>
<p>
Whether you want to use Maven or not, users of your project - especially if you provide a framework or
reusable library - may choose to use Maven. The quality of the metadata in the Maven repository is important
to your users as they list dependencies on your metadata, and link in the information into their own
projects.
</p>
<p>
Maintaining the metadata for your project is not hard - you can submit it to Maven at release time (and
for large projects it can be setup automatically), and just need to describe your project, its location,
version and most importantly dependencies. Not doing so, or providing incomplete or invalid information
leaves this responsibility to the users of your project.
</p>
<p>
The Maven team does work on this metadata actively to improve its quality, but with thousands of artifacts in
the repository and only a certain level of knowledge of other projects this is not ideal. Nobody knows your
project better than you.
</p>
</answer>
</faq>
<faq id="how-to-improve-metadata">
<question>How do I make sure my project's dependency metadata is correct?</question>
<answer>
<p>
It is best to get it right at the time of a release to avoid having to make difficult updates later on.
Your information can be submitted to Maven using the regular
<a href="http://maven.apache.org/maven2/guides/mini/guide-ibiblio-upload.html">repository upload procedure</a>
.
</p>
<p>
The following information is what is best to provide:
</p>
<ul>
<li>Project name</li>
<li>Project URL</li>
<li>License</li>
<li>Description of the project</li>
<li>Group and Artifact ID</li>
<li>Packaging</li>
<li>Version</li>
<li>Dependencies</li>
</ul>
<p>
The group ID should resemble the package name, or reverse DNS of your web site, and can contain subgroups as
you see fit: for example, org.apache.maven and org.apache.maven.plugins.
</p>
<p>
The artifact ID is specific to each artifact and by convention should be the filename, excluding
extension.
</p>
<p>
The packaging is the type of your artifact, such as jar, war, ear, ejb, dll, etc.
</p>
<p>
Each dependency also contains their group ID and artifact ID, as well as version specification.
In particular, you should ensure that optional dependencies are marked as such, and that runtime and testing
only dependencies are marked with the given scope. Ranges can be used for version if that is appropriate,
such as commons-collections [2.0,3.0). Ensure that the dependency exists in the Maven system and matches
first.
</p>
<p>
See the format of the
<a href="/maven2/maven-model/maven.html">project descriptor</a>
for more information.
</p>
</answer>
</faq>
<faq id="how-to-automatically-sync">
<question>How do I ensure my latest releases automatically appear in the Maven repository?</question>
<answer>
<p>
If you able to publish your releases to a Maven2 style repository and make it available over rsync,
we can automatically publish them to ibiblio when released. This procedure requires that you take full
responsibility for your metadata, but also ensures the best service for your users. If this is interesting
to your project, contact dev@maven.apache.org.
</p>
</answer>
</faq>
</part>
</faqs>

1
maven-site/src/site/resources/.htaccess
View File

@ -1 +0,0 @@
ErrorDocument 404 /errors/404.html

17
maven-site/src/site/resources/ant/build-a1.xml
View File

@ -1,17 +0,0 @@
<project default="compile">
<property name="classesdir=" value="..."/>
<property name="libdir" value="..."/>
<target name="compile">
<mkdir dir="${classesdir}"/>
<javac destdir="${classesdir}">
<src>
<pathelement location="src/main/java"/>
</src>
<classpath>
<fileset dir="${libdir}">
<include name="*.jar"/>
</fileset>
</classpath>
</javac>
</target>
</project>

31
maven-site/src/site/resources/ant/build-a2.xml
View File

@ -1,31 +0,0 @@
<project default="compile">
<property name="classesdir=" value="..."/>
<property name="test.classesdir=" value="..."/>
<property name="libdir" value="..."/>
<target name="compile">
<mkdir dir="${classesdir}"/>
<javac destdir="${classesdir}">
<src>
<pathelement location="src/main/java"/>
</src>
<classpath>
<fileset dir="${libdir}">
<include name="*.jar"/>
</fileset>
</classpath>
</javac>
</target>
<target name="test-compile">
<mkdir dir="${test.classesdir}"/>
<javac destdir="${test.classesdir}">
<src>
<pathelement location="src/test/java"/>
</src>
<classpath>
<fileset dir="${libdir}">
<include name="*.jar"/>
</fileset>
</classpath>
</javac>
</target>
</project>

31
maven-site/src/site/resources/ant/build-a3.xml
View File

@ -1,31 +0,0 @@
<project default="jar">
<target name="compile" description="o Compile the code" depends="get-deps">
<mkdir dir="${classesdir}"/>
<javac destdir="${classesdir}">
<src>
<pathelement location="src/main/java"/>
</src>
<classpath>
<fileset dir="${libdir}">
<include name="*.jar"/>
</fileset>
</classpath>
</javac>
</target>
<target name="test-compile" description="o Compile the code" depends="get-deps">
<mkdir dir="${test.classesdir}"/>
<javac destdir="${test.classesdir}">
<src>
<pathelement location="src/test/java"/>
</src>
<classpath>
<fileset dir="${libdir}">
<include name="/path/to/junit-3.8.1.jar"/>
</fileset>
</classpath>
</javac>
</target>
<target name="jar" description="o Create the jar" depends="compile">
<jar jarfile="target/${final.name.api}.jar"/>
</target>
</project>

Some files were not shown because too many files have changed in this diff Show More