Maven ist ein Build-System für komplexe Projekte.
mvn install:install-file -DgroupId=com.intersult -DartifactId=com.intersult.skin -Dversion=1.0-SNAPSHOT -DgeneratePom=true -Dfile=com.intersult.skin-1.0-SNAPSHOT.jar -Dpackaging=jar
Zusätzlich kann mit -Dsources=<file> und -Djavadoc=<file> die Sourcen und Javadocs installiert werden.
mvn deploy:deploy-file -DgroupId=com.intersult -DartifactId=com.intersult.skin -Dversion=1.0 -Dpackaging=jar -Dfile=target/com.intersult.skin-1.0-SNAPSHOT.jar -Durl=file://W:\deploy\repository.war -DrepositoryId=intersult-repository
C:\Java\workspace\import\agt-war>mvn deploy:deploy-file -DgroupId=ojdbc -DartifactId=ojdbc14 -Dversion=9.0.2.0.0 -Dpackaging=jar "-Dfile=C:\Java\lib\ojdbc14.jar" -DrepositoryId=intersult-repo -Durl=svn:https://intersult.com/svn/public/maven
Falls ein spezieller Wagon verwendet werden soll (Transportschicht für das Protocol-Handling), kann dieser und die Dependencies in <maven-home>/lib abgelegt werden (z.B. maven-svn-wagon-1.4.jar, svnkit-1.3.5.jar).
Beim deployen kann -Dsources=<file> und -Djavadoc=<file> nicht verwendet werden, die Files müssen getrennt hochgeladen werden mit -Dpackaging=java-source und -DgeneratePom=false
mvn glassfish:deployPlugin config:
<plugin>
<groupId>org.glassfish.maven.plugin</groupId>
<artifactId>maven-glassfish-plugin</artifactId>
<version>2.1</version>
<configuration>
<domain>
<name>domain1</name>
<adminPort>4848</adminPort>
</domain>
<glassfishDirectory>${env.GLASSFISH_HOME}</glassfishDirectory>
<user>admin</user>
<adminPassword>adminadmin</adminPassword>
<echo>true</echo>
</configuration>
</plugin>
mvn jboss:redeployPlugin config:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jboss-maven-plugin</artifactId>
<version>1.4</version>
<configuration>
<hostName>localhost</hostName>
<port>8080</port>
<serverName>default</serverName>
<fileNames>
<fileName>${project.build.directory}/${project.build.finalName}.${project.packaging}</fileName>
</fileNames>
</configuration>
</plugin>
<pluginRepository>
<id>codehaus snapshot repository</id>
<url>http://snapshots.repository.codehaus.org/</url>
<releases>
<enabled>true</enabled>
</releases>
</pluginRepository>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>${env.GLASSFISH_HOME}/bin/asadmin</executable>
<arguments>
<argument>deploy</argument>
<argument>target/test.war</argument>
</arguments>
</configuration>
</plugin>
mvn exec:exec
<profiles> <profile> <id>echo</id> <activation> <property> <name>command</name> <value>deploy</value> </property> </activation> <build> <defaultGoal>antrun:run</defaultGoal> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.3</version> <configuration> <tasks> <echo>Hello World!</echo> </tasks> </configuration> </plugin> </plugins> </build> </profile> </profiles> mvn -Dcommand=echo
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>compile</id>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo message="${os.family}"/>
<echo message="${os.arch}"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
Tests können so nicht debuggt werden, da für sie eine eigene VM erzeugt wird. Dies kann verhindert werden, indem das Surefire-Plugin konfiguriert wird:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.10</version> <configuration> <forkMode>never</forkMode> </configuration> </plugin>
Allerdings können sich dann Probleme mit dem Classpath ergeben.
<profile>
<id>hudson</id>
<activation>
<property>
<name>BUILD_NUMBER</name>
</property>
</activation>
...
</profile>
<servers> <server> <id>intersult-repo</id> <username>username</username> <password>passwort</password> </server> </servers>
<profiles>
<profile>
<id>win-32bit</id>
<activation>
<os>
<family>windows</family>
<arch>x86</arch>
</os>
</activation>
<properties>
<some.classifier>win-32bit</some.classifier>
</properties>
</profile>
<profile>
<id>win-64bit</id>
<activation>
<os>
<family>windows</family>
<arch>amd64</arch>
</os>
</activation>
<properties>
<some.classifier>win-64bit</some.classifier>
</properties>
</profile>
</profiles>
<proxies> <proxy> <id>[id]</id> <active>true</active> <protocol>http</protocol> <host>[host]</host> <port>[port]</port> <nonProxyHosts>127.0.0.*|localhost|10.1.*</nonProxyHosts> </proxy> </proxies>
Beim Verwenden von Subversion-Operationen, zum Beispiel deploy:deploy-file ist zusätzlich das SVN-Proxy im Subversion unter %APPDATA%\Subversion\servers anzugeben:
[global] http-proxy-host = [host] http-proxy-port = [port] http-proxy-exceptions = 127.0.0.*, localhost, 10.1.*
Die eigentlich Wagons sind mit einer Annotation versehen:
/**
* IntersultHttpWagon
*
* @plexus.component role="org.apache.maven.wagon.Wagon" role-hint="http-intersult"
* instantiation-strategy="per-lookup"
*/
public class IntersultHttpWagon extends StreamWagon {
...
Will man die Wagons verwenden, werden die im Build-Prozess des Target-Projecte einfach als Build-Extension eingebunden.
<build>
<extensions>
<extension>
<groupId>com.intersult</groupId>
<artifactId>wagon-http-intersult</artifactId>
<version>1.0-SNAPSHOT</version>
</extension>
</extensions>
...
Das Aktivieren als Default-Wagon für ein Protokoll (also HTTP, HTTPS etc.) erfolgt durch das Build-Kommando:
mvn -Dmaven.wagon.provider.http=intersult install
Oder permanent in der settings.xml für bestimmte Server:
<server> <id>intersult-repo</id> <configuration> <wagonProvider>intersult</wagonProvider> </configuration> </server>
Grundsätzlich hat Maven eine Fallback-Strategie, wenn der Wagon (noch) nicht geladen werden kann. Dies tritt insbesondere während des Bootstrap von Maven auf. Maven führt in diesem Fall generell einen Fallback auf die Standard-Wagons aus. Allerdings funktioniert das nicht, wenn der zu ladende Wagon sich in einem Repository befindet, für das genau dieser Wagon benötigt wird.
<project>
...
<packaging>maven-plugin</packaging>
...
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-project</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.sonatype.plexus</groupId>
<artifactId>plexus-build-api</artifactId>
<version>0.0.7</version>
</dependency>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-utils</artifactId>
<version>1.5.8</version>
</dependency>
...
</dependencies>
...
</project>
Anlegen eines sogenannten Mojos (Maven-Pojo). Parameter können statisch mit defaults, aus Maven-Parametern durch Expressions oder aus der Plugin-Konfiguration injeziert werden.
/**
* @goal encode
* @phase generate-resources
*/
public class EncodingMojo extends AbstractMojo {
/*
* @parameter default-value="src/main/resources"
*/
protected File src;
/**
* @parameter expression="${project}"
* @readonly
*/
protected MavenProject project;
/**
* @parameter
* @required
*/
protected Resource resource;
/** @component */
private BuildContext buildContext;
@Override
public void execute() throws MojoExecutionException, MojoFailureException {
...
}
...
}
Bei Verwendung in Eclipse ab Indigo wird das Maven-Plugin von Eclipse selbst geliefert (M2E). Dies erfordert eine erweiterte Konfiguration des Plugins, da es sonst zu Fehlern im Lifecycle kommt. Dazu wird eine Datei angelegt /<project>/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml
<?xml version="1.0" encoding="UTF-8"?> <lifecycleMappingMetadata> <pluginExecutions> <pluginExecution> <pluginExecutionFilter> <goals> <goal>generate-schema</goal> </goals> </pluginExecutionFilter> <action> <execute> <runOnIncremental>false</runOnIncremental> <runOnConfiguration>true</runOnConfiguration> </execute> </action> </pluginExecution> </pluginExecutions> </lifecycleMappingMetadata>
Version 3.0.4 verwendet nun wieder HttpClient 4.1.2. Diese Version arbeitet generell wieder besser als die Versionen Maven 2.*, allerdings geht kein transparentes NTML mehr (Windows-Authentifizierung). In diesem Fall ist 3.0.3 zu verwenden.