jvanzyl 2004/06/04 13:11:46
Added: maven-core/docs/apt alpha-release-criteria.apt
configuration-management.apt mojos.apt
plugin-descriptors.apt plugins.apt
Log:
o i have amalgamated the unified source tree and POM encapsulation wiki
docs into this document which I am still working on while I fiddle with
some diagrams and code.
Revision Changes Path
1.1 maven-components/maven-core/docs/apt/alpha-release-criteria.apt
Index: alpha-release-criteria.apt
===================================================================
-----
Maven alpha release criteria
-----
Jason van Zyl
-----
Maven alpha release criteria
Anything that is listed as done is really only in its first working form
and can be improved but it is working nonetheless.
* Continuous integration for the core
* Security policy for uploads
* Plugin test harness (done)
* Plugin development guide
* Plugin doco generator (done)
* Strategy for dealing with generated sources (done)
* sites for all components
* generation of model documentation (done)
* generation of model XSD (done)
* v3 to v4 model converter
1.1
maven-components/maven-core/docs/apt/configuration-management.apt
Index: configuration-management.apt
===================================================================
-----
Maven configuration management
-----
Jason van Zyl
-----
Configuration levels in maven
In maven configuration control happens on four differ levels: the site level, the
group level,
the project level, and the user level. On the site level you can configure maven
for all users
utilizing the local installation, the group level allows configuration management
for all the projects
that belong to the same group, the project level allows configuration management at
the project level, and the user level allows users to override settings on
the site level, group level and project level.
* Site configuration
At the site level all configuration is achieved by tweaking the the various files
that
are available in the ${maven.home}/site-configuration directory
+-----+
${maven.home}
|
+--- site-configuration
|
+--- plugins.xml
|
+--- maven.properties
+-----+
* Group configuration
As far as properties go for an entire build the maven.properties could be placed at
the top of the group but I'm not really sure how this might work. There could
probably
also be a directory for plugins.xml and maven.properties.
* Project configuration
At the project level all configuration is achieved by tweaking the POM. One of the
differences between
maven 1.x and 2.x is that all project parameterization occurs in the POM and not
from properties
files.
For many of the more advanced features in Maven2 it is critical that POMs be
available in the local repository.
Features like transitive dependencies and the new parent specification mechanism.
The problem we run into is
that currently we have information about a project scattered across the project.xml
and the
various properties files. What needs to be done is to encapsulate all of this in
the POM.
Typically users parameterize the use of plugins, or have custom values like
${user.name}
for use in elements like the <developerConnection/>. It would be idea if we
could encapsulate everything we need about the project in the POM including
plugin parameters and anything else.
We once had a document that Vincent and I agreed upon and I was about to
implement it and then I disappeared for 8 months so it never came to pass.
So I guess it's important to figure out what people are using propeties
files for and see if we can't incorporate it all into the POM. Or if we do
have properties file (something I would like to avoid) say they don't
contribute in any meaningful way to information in the POM. For example a
properties file could be used the specify $ so it can be interpolated in
<developerConnection/> but you couldn't use a properties file to specify the
version of your project say. Anyway, food for thought to begin with.
- elements that are critical for pom dissemination
- those that are used locally by the user like <developerConnection/>
* User configuration
User configuration which is utilized site wide are controlled with the
${user.home}/maven.properties.
User configuration which is utilized at the project level are controlled with the
${project.home}/maven.properties file.
Plugin configuration
The configuration of plugins is of the same form as the maven
{{{plugin-descriptors}plugin descriptors}}
themselves:
+-----+
<plugins>
<plugin>
<id>xdoc</id>
<version>1.0</version>
<parameters>
<parameter>
<name>theme</name>
<value>classic</value>
</parameter>
</parameters>
</plugin>
</plugins>
+-----+
Unified source directory
Unified source directory structure that is analagous to the repository
itself. This way locations of intermediary artifacts of a build would be
in a known location. This would also help with developer setup i.e. getting
new developers up and running. They could run a maven command and have all
their source trees set up in the same way as their collegues.
here's what I do currently in the netbeans part of the mevenide project to
find the relevant subprojects/sibling projects. I check if the user has
defined the maven.multiproject.includes property in any of his properties
files for the current project. if yes. then I'm able to find projects that
can be offered to be opened together with the current project.
problems with the current solution are:
1. information is duplicate. once in POM's dependencies and once in the
maven.multiproject.includes property.
2. it works without problems only for projects with relative paths, eg. from
one CVS repository.. for projects from multiple SCM repositories it's harder
to maintain the same relative links on all developer computers.
not sure the unified source directory structure addresses this issue.
1.1 maven-components/maven-core/docs/apt/mojos.apt
Index: mojos.apt
===================================================================
-----
Maven Java objects (Mojos)
-----
Jason van Zyl
----
Maven Java objects
Maven Java objects try to be the simplest form of Java object that can be
+-----+
public class CompilerMojo
extends AbstractMojo
{
public void execute( MojoRequest request, MojoResponse response )
{
// Extract parameters from the request
String sourceDirectory = (String) request.getParameter( "sourceDirectory" );
String outputDirectory = (String) request.getParameter( "outputDirectory" );
try
{
compiler.compile( sourceDirectory, outputDirectory );
}
catch( Exception e )
{
response.setException( e );
}
}
}
+-----+
o trying to alleviate the need to log internally by gleaning information
from the response.
1.1 maven-components/maven-core/docs/apt/plugin-descriptors.apt
Index: plugin-descriptors.apt
===================================================================
-----
Maven plugin descriptors
-----
Jason van Zyl
-----
Maven plugin descriptors
+-----+
<plugin>
<id>compiler</id>
<implementation>org.apache.maven.plugin.CompilerPlugin</implementation>
<parameters>
<parameter>
<name>sourceDirectory</name>
<type>String</type>
<required>false</required>
<validator>validator</validator>
<description></description>
</parameter>
<parameter>
<name>outputDirectory</name>
<type>String</type>
<required>false</required>
<validator>validator</validator>
<description></description>
</parameter>
<parameter>
<name>classpathElements</name>
<type>String[]</type>
<required>false</required>
<validator>validator</validator>
<description></description>
</parameter>
<parameter>
<name>compiler</name>
<type>String</type>
<required>false</required>
<validator>validator</validator>
<description></description>
</parameter>
</parameters>
<goals>
<goal>
<name>compile</name>
<description>Compiles application sources</description>
<parameters>
<parameter>
<name>sourceDirectory</name>
<expression>#project.build.sourceDirectory</expression>
</parameter>
<parameter>
<name>outputDirectory</name>
<expression>#maven.build.dest</expression>
</parameter>
<parameter>
<name>classpathElements</name>
<expression>#project.classpathElements</expression>
</parameter>
</parameters>
</goal>
<goal>
<name>test:compile</name>
<description>Compiles test sources</description>
<parameters>
<parameter>
<name>sourceDirectory</name>
<expression>#project.build.unitTestSourceDirectory</expression>
</parameter>
<parameter>
<name>outputDirectory</name>
<expression>#maven.test.dest</expression>
</parameter>
<parameter>
<name>classpathElements</name>
<expression>#project.classpathElements</expression>
</parameter>
</parameters>
<prereqs>
<prereq>compile</prereq>
</prereqs>
</goal>
</goals>
</plugin>
+-----+
1.1 maven-components/maven-core/docs/apt/plugins.apt
Index: plugins.apt
===================================================================
-----
Maven plugins
-----
Jason van Zyl
-----
Maven plugins
Maven plugins are comprised of any number of {{{mojos}mojos}} which are simple
classes that
perform a single action and goals that are a parameterized execution of a mojo.
Goals can also be a different parameterization of the same mojo.
This definition could certainly be refined and cleaned up with some examples
and diagrams.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
