I am trying to implement the solution mentioned in How to specify jetty-env.xml file for Maven Cargo plugin for Jetty?
However I am facing something even more fundamental: My Cargo is simply not generating any context xml.
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.2.1</version>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
<!-- Configuration to use with the container or the deployer -->
<configuration>
<properties>
<cargo.servlet.port>${itest.webapp.port}</cargo.servlet.port>
<cargo.jetty.createContextXml>true</cargo.jetty.createContextXml>
</properties>
<deployables>
<deployable>
<groupId>${project.groupId}</groupId>
<artifactId>myApp-web</artifactId>
<type>war</type>
<properties>
<context>/myApp</context>
</properties>
</deployable>
</deployables>
<!--
<configfiles>
<configfile>
<file>${project.build.outputDirectory}/jetty-env.xml</file>
<todir>contexts</todir>
<tofile>${jetty6.context}.xml</tofile>
</configfile>
</configfiles>
-->
</configuration>
</configuration>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
The basic idea is, we are providing the a custom context.xml to replace the one generated. However, when I am trying out, I cannot find any context XML generated by Cargo (Please note that I have remarked the custom config files, and with cargo.jetty.createContextXml being true)
I am not sure if it is my problem in setting causing the context not generated, or the context is generated somewhere I overlooked. I have checked under target/cargo/ and the temp directory that cargo expanded my WAR, neither place contains the context xml.
(I am using Maven 2.2.1, Cargo 1.2.1, JDK 6)
I am not 100% sure what your problem is, but here is what cargo does on my system for Jetty6.
The directory where the Jetty installation is NOT where the runtime context and webapp files are. In my case, they are stored in the Java temp directory (i.e. java.io.tmpdir). On my Ubuntu system this is /tmp. Under this directory, there is a cargo/conf directory. Under /tmp/cargo/conf I have a contexts directory where the context.xml file is stored -- although the actual name of the file is never context.xml it is always named after the web app context.
In my case, this file is given the same name as the context I configured cargo with. Herein may lie your problem because I noticed that you did not supply a context as I do:
<deployables>
<deployable>
<properties>
<!-- Web root context URL -->
<context>${build.appserver.context}</context>
</properties>
</deployable>
</deployables>
Secondly, I also noticed you have commented out the section that places the context.xml file in the right place. Unless you uncomment that, this isn't going to work.
Thirdly, did you set the value of the ${jetty6.context} Maven property?
Fourthly - I think for this to work you need to use a standalone configuration of Jetty. This shouldn't be a problem as Cargo will automatically download and install it for you. See my config here:
<container>
<containerId>jetty6x</containerId>
<!-- Using Jetty for build portability so type != "remote". For Jetty
would prefer type = "embedded" but we must go with "installed" because jetty-env.xml
file would be ignored. See http://jira.codehaus.org/browse/CARGO-861 -->
<type>installed</type>
<zipUrlInstaller>
<url>http://dist.codehaus.org/jetty/jetty-6.1.26/jetty-6.1.26RC0.zip</url>
<installDir>${build.working}</installDir>
</zipUrlInstaller>
<dependencies>
<!-- The following dependencies are added to the servlet container's
classpath as if they were installed by a system admin. In order to be included
here, they need to be listed as dependencies in this pom.xml. -->
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc5</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
<dependency>
<groupId>net.sourceforge.jtds</groupId>
<artifactId>jtds</artifactId>
</dependency>
</dependencies>
</container>
<!-- Do not hang and wait for a client, just do it -->
<wait>false</wait>
<configuration> <!-- Deployer configuration -->
<!-- Running Jetty container with type=installed (e.g. local) so
type != "runtime", and we are installing it during this execution for the
sake of portability so type != "existing" -->
<type>standalone</type>
<properties>
<!-- Use the port number from settings.xml -->
<cargo.servlet.port>${build.appserver.port}</cargo.servlet.port>
</properties>
<deployables>
<deployable>
<properties>
<!-- Web root context URL -->
<context>${build.appserver.context}</context>
</properties>
</deployable>
</deployables>
<configfiles>
<configfile>
<file>${basedir}/target/jetty-context.xml</file>
<todir>contexts</todir>
<tofile>${build.appserver.context}.xml</tofile>
</configfile>
</configfiles>
</configuration>
Related
I'm trying to package a jboss AS7.5 module (RedHat EAP 6.4) that includes a valve. That valve requires a binding to the AuthenticatorBase that comes with the tomcat-catalina-x.y.z.jar, which does not (to my knowledge) come as a downloadable module in its own right. So, I need to build that jar into my module, using the maven plugin for packaging with dependencies.
Problem is, the GAV for the dependency, org.apache.tomcat:tomcat-catalina:x.y.z, includes libraries that ARE included in AS, namely the servlet libraries. If I package the catalina dependency, using the maven plugin that does that, I get a bunch of unnecessary jars that break my module at runtime.
Is there a way to
only package the jar(s) I want?
find a different dependency that includes just the tomcat valve (i.e., the jar containing org.apache.catalina.authenticator.AuthenticatorBase) binding?
or, preferably, is there a module that already exists for exactly this purpose, one that I can reference as a module dependency in my module.xml file?
<dependencies>
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-catalina</artifactId>
<version>${tomcat-catalina.version}</version>
</dependency>
...
</dependencies>
includes jars: tomcat-catalina, tomcat-servlet, tomcat-juli, tomcat-annotations, etc.
<build>
<plugins>
<plugin>
<!-- NOTE: We don't need a groupId specification because the group is
org.apache.maven.plugins ...which is assumed by default. -->
<artifactId>maven-assembly-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- bind to the packaging phase -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
How to get only tomcat-catalina.jar in my packaged module?
I need to produce a simple app for my customer configure and run at their site. I am using the Spring framework, so I have a number of config files that must be on the class path. I am using Maven2 with Netbeans as my IDE.
I am able to create and run my app using Netbeans/Maven and I am using the Application Assembler Maven plugin to generate the runnable application. All this works fine except that my Spring config files have to be placed in src/main/resources which means that they get packaged into the resulting JAR file.
I need my customer to be able to modify the config files to do their testing, but it's not reasonable to ask them to modify the copies that are packaged in the JAR.
There are perhaps a number of solutions, but it seems to me that the simplest would be to get Maven to not package the app and the config files into a JAR at all, just leaving them in something like a classes directory from which they can be run. This would allow the user to modify the config files easily. Unfortunately I can't figure out how to get Maven to "package" the app in this manner, or how to get the AppAssembler to generate the resulting runnable.
Here is an extract of my pom.xml that may help illustrate what I am trying to do:
...
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.1.0.RELEASE</version>
</dependency>
... stuff deleted ...
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<!-- Set the target configuration directory to be used in the bin scripts -->
<configurationDirectory>conf</configurationDirectory>
<!-- Copy the contents from "/src/main/config" to the target
configuration directory in the assembled application -->
<copyConfigurationDirectory>true</copyConfigurationDirectory>
<!-- Include the target configuration directory in the beginning of
the classpath declaration in the bin scripts -->
<includeConfigurationDirectoryInClasspath>
true
</includeConfigurationDirectoryInClasspath>
<platforms>
<platform>windows</platform>
</platforms>
<programs>
<program>
<mainClass>org.my.path.App</mainClass>
<name>app</name>
</program>
</programs>
</configuration>
</plugin>
</plugins>
</build>
...
Neither single packed jar file or bunch of unpacked classes files are good format for professional client delivery. Look at those brilliant apache apps like tomcat, ant and maven, they are shipped as a tar.gz or zip file, after download, simply extract them and you will get a nice and clean directory structure:
conf --> put config file like *.properties, logback.xml here
doc --> readme.txt, userguide.doc etc
lib --> put you core.jar with dependency jar file here
run.bat --> run script for Windows
run.sh --> run script for Unix
We can do these kinds of stuff with Maven as well. Note that you should design and implement your core jar to read *.properties from the conf directory properly. then use maven-assembly-plugin pack you app into this classical directory structure.
Sample pom.xml for a command-line app:
<!-- Pack executable jar, dependencies and other resource into tar.gz -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-5</version>
<executions>
<execution>
<phase>package</phase>
<goals><goal>attached</goal></goals>
</execution>
</executions>
<configuration>
<descriptors>
<descriptor>src/main/assembly/binary-deployment.xml</descriptor>
</descriptors>
</configuration>
</plugin>
Sample binary-deployment.xml for a command-line app:
<!--
release package directory structure:
*.tar.gz
conf
*.xml
*.properties
lib
application jar
third party jar dependencies
run.sh
run.bat
-->
<assembly>
<id>bin</id>
<formats>
<format>tar.gz</format>
</formats>
<includeBaseDirectory>true</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>src/main/java</directory>
<outputDirectory>conf</outputDirectory>
<includes>
<include>*.xml</include>
<include>*.properties</include>
</includes>
</fileSet>
<fileSet>
<directory>src/main/bin</directory>
<outputDirectory></outputDirectory>
<filtered>true</filtered>
<fileMode>755</fileMode>
</fileSet>
<fileSet>
<directory>src/main/doc</directory>
<outputDirectory>doc</outputDirectory>
<filtered>true</filtered>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
<useProjectArtifact>true</useProjectArtifact>
<unpack>false</unpack>
<scope>runtime</scope>
</dependencySet>
</dependencySets>
</assembly>
If not misleading, I think you want to let the jar and config to be separated, with jar exposed for client's testing.
The following can do this for you using copy-maven-plugin, it can accomplish almost tasks what assembly-plugin would do ,ex: copy, dependency and much more - download, upload ,move ,... .
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>copy-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>create-archive</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
</execution>
</executions>
<configuration>
<resources>
<!--copy your scripts to ${myOutPutPath}/bin-->
<resource>
<targetPath>${myOutPutPath}/bin</targetPath>
<directory>${project.basedir}/src/main/scripts</directory>
<includes>
<include>*</include>
</includes>
</resource>
<resource>
<!--copy your configs-->
<targetPath>${myOutPutPath}/conf</targetPath>
<directory>${project.basedir}/src/main/config</directory>
<include>*</include>
</resource>
</resources>
</configuration>
</plugin>
Package main jar and put to your ${myOutPutPath}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<!-- The configuration of the plugin -->
<configuration>
<outputDirectory>${myOutPutPath}</outputDirectory>
<!-- Configuration of the archiver -->
<archive>
<!-- Manifest specific configuration -->
<manifest>
<!-- Classpath is added to the manifest of the created jar file. -->
<addClasspath>true</addClasspath>
<!--
Configures the classpath prefix. This configuration option is
used to specify that all needed libraries are found under lib/
directory.
-->
<classpathPrefix>lib/</classpathPrefix>
<!-- Specifies the main class of the application -->
<mainClass>com.xinguard.snmp.SNMP_ETL</mainClass>
</manifest>
<!-- you need to add some classpath by yourself, like conf here for client to use-->
<manifestEntries>
<Class-Path>conf/</Class-Path>
</manifestEntries>
</archive>
</configuration>
</plugin>
then package the lib jar to lib directory under jar directory.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${myOutPutPath}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
I see that supports GlassFish v3, but the online examples is sparse. I continue to get the same error back from cargo:
Cannot find the GlassFish admin CLI JAR: admin-cli.jar
Here is my pom
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.0.3</version>
<configuration>
<container>
<containerId>glassfish3x</containerId>
<type>installed</type>
</container>
<configuration>
<type>standalone</type>
<home>C:\glassfishv3</home>
<properties>
<cargo.hostname>localhost</cargo.hostname>
<cargo.servlet.port>8082</cargo.servlet.port>
<cargo.remote.username></cargo.remote.username>
<cargo.remote.password></cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>installed</type>
<deployables>
<deployable>
<groupId>${groupId}</groupId>
<artifactId>${artifactId}</artifactId>
<type>war</type>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
corrected Pom:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.0.3</version>
<configuration>
<container>
<containerId>glassfish3x</containerId>
<type>installed</type>
<home>C:\glassfishv3</home>
</container>
<configuration>
<type>standalone</type>
<properties>
<cargo.hostname>localhost</cargo.hostname>
<cargo.servlet.port>8082</cargo.servlet.port>
<!-- if no username/password don't use these, it will fail
<cargo.remote.username></cargo.remote.username>
<cargo.remote.password></cargo.remote.password> -->
</properties>
</configuration>
<deployer>
<type>installed</type>
<deployables>
<deployable>
<groupId>${groupId}</groupId>
<artifactId>${artifactId}</artifactId>
<type>war</type>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
In your Glassfish installation, do you have the admin-cli.jar file present in modules directory?
For more information about this module, check this link.
Edit
It seems that you have a problem in your configuration. As you can see here, there are several <home> nodes that can be used in the <configuration> of the Cargo plugin.
If you define the <home> inside the <configuration> tag, like you do in your pom.xml, this tag is used for:
For standalone configuration this is the location where Cargo will create the configuration and for existing configuration this is where it is located
However, in your case, you must move the <home> in the <container> tag. As described in the link above, this <home> is used for:
Location where the container is installed.
I am not able to use yui-compressor maven plugin in my web app. When I run maven I get following error
[INFO] Internal error in the plugin manager executing goal 'net.sf.alchim:yuicompressor-maven-plugin:0.7.1:compress': Unable to load the mojo 'net.sf.alchim:
yuicompressor-maven-plugin:0.7.1:compress'
in the plugin 'net.sf.alchim:yuicompressor-maven-plugin'. A required class is missing: org.mozilla.javascript.ErrorReporter
Later I found that rhino js plugin contains this class org.mozilla.javascript.ErrorReporter. So I included this plugin in dependency tag but still I am getting the same error.
Has anyone came across such error.
--> updating main question to add the pom plugin details
<plugin>
<groupId>net.sf.alchim</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>0.7.1</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>jslint</goal>
<goal>compress</goal>
</goals>
</execution>
</executions>
<configuration>
<failOnWarning>true</failOnWarning>
<nosuffix>true</nosuffix>
<aggregations>
<aggregation>
<!-- remove files after aggregation (default: false) -->
<removeIncluded>false</removeIncluded>
<!-- insert new line after each concatenation (default: false) -->
<insertNewLine>false</insertNewLine>
<output>${project.basedir}/${webcontent.dir}/js/compressedAll.js</output>
<!-- files to include, path relative to output's directory or absolute path-->
<!--inputDir>base directory for non absolute includes, default to parent dir of output</inputDir-->
<includes>
<include>**/autocomplete.js</include>
<include>**/calendar.js</include>
<include>**/dialogs.js</include>
<include>**/download.js</include>
<include>**/folding.js</include>
<include>**/jquery-1.4.2.min.js</include>
<include>**/jquery.bgiframe.min.js</include>
<include>**/jquery.loadmask.js</include>
<include>**/jquery.printelement-1.1.js</include>
<include>**/jquery.tablesorter.mod.js</include>
<include>**/jquery.tablesorter.pager.js</include>
<include>**/jquery.validate.js</include>
<include>**/jquery-ui-1.8.custom.min.js</include>
<include>**/languageDropdown.js</include>
<include>**/messages.js</include>
<include>**/print.js</include>
<include>**/tables.js</include>
<include>**/tabs.js</include>
<include>**/uwTooltip.js</include>
</includes>
<!-- files to exclude, path relative to output's directory-->
</aggregation>
</aggregations>
</configuration>
<dependencies>
<dependency>
<groupId>rhino</groupId>
<artifactId>js</artifactId>
<scope>compile</scope>
<version>1.6R5</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0.7</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-project</artifactId>
<version>2.0.7</version>
<scope>provided</scope>
</dependency><dependency>
<groupId>net.sf.retrotranslator</groupId>
<artifactId>retrotranslator-runtime</artifactId>
<version>1.2.9</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</plugin>
Could you try the latest version (1.1)?
The 0.7.1 version doesn't even seem to be on the official repository. Maybe a dependency resolution problem?
See the topic Yui compressor StringIndexOutOfBoundsException on jboss
The only way to use yuicompressor on web app is to manually merge it with rhino dependency. Otherwise, the app to run would require specifying required sequence of jars in classloader loading sequence (youcompressor must go before rhino).
I struggled with the ErrorReporter class missing too. I solved it by building a jar-with-dependencies which I then turned around to use in my web app,
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>attached</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
Once I did that, everything worked. In my jar I could see that the org.mozilla.javascript.ErrorReporter.class was in there and Maven would then compile for me.
My goal is to take a Grails web application and build it into a Web ARchive (WAR file) using Maven, and the key is that it must populate the "plugins" folder without live access to the internet. An "out of the box" Grails webapp will already have the plugins folder populated with JAR files, but the maven build script should take care of populating it, just like it does for any traditional WAR projects (such as WEB-INF/lib/ if it's empty)
This is an error when executing mvn grails:run-app with Grails 1.1 using Maven 2.0.10 and org.grails:grails-maven-plugin:1.0. (This "hibernate-1.1" plugin is needed to do GORM.)
[INFO] [grails:run-app]
Running pre-compiled script
Environment set to development
Plugin [hibernate-1.1] not installed, resolving..
Reading remote plugin list ...
Error reading remote plugin list [svn.codehaus.org], building locally...
Unable to list plugins, please check you have a valid internet connection: svn.codehaus.org
Reading remote plugin list ...
Error reading remote plugin list [plugins.grails.org], building locally...
Unable to list plugins, please check you have a valid internet connection: plugins.grails.org
Plugin 'hibernate' was not found in repository. If it is not stored in a configured repository you will need to install it manually. Type 'grails list-plugins' to find out what plugins are available.
The build machine does not have access to the internet and must use an internal/enterprise repository, so this error is just saying that maven can't find the required artifact anywhere. That dependency is already included with the stock Grails software that's installed locally, so I just need to figure out how to get my POM file to unpackage that ZIP file into my webapp's "plugins" folder.
I've tried installing the plugin manually to my local repository and making it an explicit dependency in POM.xml, but it's still not being recognized. Maybe you can't pull down grails plugins like you would a standard maven reference?
mvn install:install-file -DgroupId=org.grails -DartifactId=grails-hibernate -Dversion=1.1 -Dpackaging=zip -Dfile=%GRAILS_HOME%/plugins/grails-hibernate-1.1.zip
I can manually setup the Grails webapp from the command-line, which creates that local ./plugins folder properly. This is a step in the right direction, so maybe the question is: how can I incorporate this goal into my POM?
mvn grails:install-plugin -DpluginUrl=%GRAILS_HOME%/plugins/grails-hibernate-1.1.zip
Here is a copy of my POM.xml file, which was generated using an archetype.
<?xml version="1.0" encoding="UTF-8"?>
<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.samples</groupId>
<artifactId>sample-grails</artifactId>
<packaging>war</packaging>
<name>Sample Grails webapp</name>
<properties>
<sourceComplianceLevel>1.5</sourceComplianceLevel>
</properties>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-crud</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-gorm</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>
<version>2.4</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
<exclusion>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
<!--
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-hibernate</artifactId>
<version>1.1</version>
<type>zip</type>
</dependency>
-->
</dependencies>
<build>
<pluginManagement />
<plugins>
<plugin>
<groupId>org.grails</groupId>
<artifactId>grails-maven-plugin</artifactId>
<version>1.0</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>init</goal>
<goal>maven-clean</goal>
<goal>validate</goal>
<goal>config-directories</goal>
<goal>maven-compile</goal>
<goal>maven-test</goal>
<goal>maven-war</goal>
<goal>maven-functional-test</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${sourceComplianceLevel}</source>
<target>${sourceComplianceLevel}</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
This is a tricky problem. I was going to suggest using Grails 1.3, which allows you to pull Grails plugins from Maven-compatible repositories, but I don't think this helps with Maven (at the moment).
So, I'm going to suggest something I haven't tried myself, but may work. I have some confidence because I wrote the relevant code in the Grails Maven plugin ;) No guarantees though.
With that out of the way, let's get started. First, you need to grab the code for the relevant Grails plugins. For example, you can get Hibernate from here:
http://svn.codehaus.org/grails/trunk/grails-plugins/grails-hibernate/tags/RELEASE_1_1/
You just need a copy of the code, so a read-only checkout will be fine.
Once you have the code, run mvn grails:create-pom -DgroupId=org.grails.plugins from the root of the plugin project. This will generate a POM. Next, you will need to edit the POM and change the packaging to "grails-plugin". You should also be able to remove the <executions> block from the Grails Plugin configuration.
The POM will now allow you to build and package the Hibernate plugin, but you still have to deploy it. So add your local repository to the POM's distribution management and run mvn deploy. Once that's done, you should be able to add the plugin as a standard dependency in your application's POM.
It's hard work, but at least you should only have to do it once per version of the plugin!
I was able to come up with a workaround just to get up and running.
This requires Grails be installed locally and that GRAILS_HOME be set. It will clear out and then populate the project's "plugins" folder during the maven "validate" phase. (Insert this into the POM above.)
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<!-- clear out this project's plugins folder if it exists, otherwise you will get prompted to upgrade it after re-building -->
<delete dir="${basedir}/plugins/" includeemptydirs="true"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.grails</groupId>
<artifactId>grails-maven-plugin</artifactId>
<version>1.0</version>
<extensions>true</extensions>
<executions>
<execution>
<id>create plugins folder</id>
<phase>validate</phase>
<goals>
<goal>install-plugin</goal>
</goals>
<configuration>
<pluginUrl>${env.GRAILS_HOME}/plugins/grails-hibernate-1.1.zip</pluginUrl>
</configuration>
</execution>
</executions>
</plugin>
</plugins>