Category Archives: Maven

Posts on maven plugins, plugins configuration … etc

Maven Configuration to deploy on install phase using maven-antrun-plugin

“pom.xml” content

Add the following properties to define deployment context:

<properties>
	<filename>${project.build.finalName}.${project.packaging}</filename>
	<deployable>${basedir}/target/${filename}</deployable>
	<deploydir>/sharing/vm/</deploydir>
</properties>

Then add the following plugin configuration:

<plugin>
	<artifactId>maven-antrun-plugin</artifactId>
	<version>1.8</version>
	<executions>
		<execution>
			<id>clean</id>
			<phase>pre-clean</phase>
			<goals>
				<goal>run</goal>
			</goals>
			<configuration>
				<target name="undeploy">
					<delete file="${deploydir}/${filename}" />
				</target>
			</configuration>
		</execution>

		<execution>
			<id>deploy</id>
			<phase>install</phase>
			<goals>
				<goal>run</goal>
			</goals>
			<configuration>
				<target name="deploy">
					<copy file="${deployable}" todir="${deploydir}" />
				</target>
			</configuration>
		</execution>
	</executions>
</plugin>
Advertisements

Solving the “Plugin execution not covered by lifecycle configuration” error in Eclipse

In a recent project, we were using the “xmlbeans-maven-plugin” for XML parsing with the “xmlbeans” goal configured on the plugin. However we get this annoying error message about lifecycle configuration on Eclipse “Plugin execution not covered by lifecycle configuration”!

To fix this, one solution consists of adding an ignore configuration to the pom.xml file that says to eclipse to ignore that goal on validation. I personally don’t like this solution because It pollutes the project pom.xml file with IDE specific stuff; and this solution is specific to the project, i.e. you could have this problem on other projects and you just want to fix once for all.

The other solution, that I personally advise, is to add that same configuration to the lifecycle mappings file of the m2e eclipse plugin:

    1. Open the Eclipse preferences window and open the maven preferences page:

2014-05-14_1135

  1. Open the mapping file with “Open workspace lifecycle mappings metadata” and add the following configuration (actually this configuration is the same as the one that is inserted into the project pom file with the help of the “quick-fix” menu):
<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
	<pluginExecutions>
		<pluginExecution>
			<pluginExecutionFilter>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>xmlbeans-maven-plugin</artifactId>
				<versionRange>2.3.3</versionRange>
				<goals>
					<goal>xmlbeans</goal>
				</goals>
			</pluginExecutionFilter>
			<action>
				<ignore />
			</action>
		</pluginExecution>
	</pluginExecutions>
</lifecycleMappingMetadata>

This solution will fix the problem for all the projects in your workspace.

Context

  • Eclispe 3.7
  • Maven 2.x
  • m2e eclispe plugin

 

Spring MVC along with Spring Security 3.1 maven archetype

In a previous post I posted an article on a Spring MVC (with Apache Tiles) maven archetype project and I explained how to initiate such a Maven project using the supplied archetype.

In this post, I come with a new archetype that allows you initiate, via a single command line, a maven web project that is configured to use Spring MVC 3.1.4 along with Spring Security. Knowing how it can be sometimes painful to configure such a project and to overcome dependencies issues (version conflicts, missing dependencies issues and configuration issues), I wanted to share that with you.

The project is configured to use:

  • Spring MVC 3.1.4
  • Spring Security 3.1.4
  • Apache Tiles 2.2.2
  • Servlets API 2.5 (as provided)
  • jstl 1.2

The project comes up with the following configuration:

  1. Spring MVC is configured to Intercept /spring context requests: locate the file spring-servlet.xml
  2. Spring security is configured with two users, a regular user role user and an admin role user: locate the file spring-security.xml, it contains the two users logins and passwords
  3. (JSP) Tiles pages (view parts) are in the WEB-INF/jsp: users folder contains user role jsp pages and admin folder contains admin role jsp pages
  4. As examples, two servlets are pre-configured for each of the two users: the AdminPage1Controller.java and the Page1Controller.java
  5. The sidebar menu.jsp contains an example on how to filter content so that some content is only displayed when admin is connected

In order to use the archetype to initiate such a new maven project:

  1. Download the archetype maven project here and install it to your local repository using the following command
    mvn install:install-file -Dfile=springmvc3.1-security-archetype-1.0.0.jar -DgroupId=com.michir.projects -DartifactId=springmvc3.1-security-archetype -Dversion=1.0.0 -Dpackaging=jar -DgeneratePom=true [-DlocalRepositoryPath=[path to your local repository]]
    
  2. Once installed, generate your Spring MVC – Security project using the following maven command
    mvn archetype:generate -DarchetypeGroupId=com.michir.projects -DarchetypeArtifactId=springmvc3.1-security-archetype -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=myproject -Dversion=1.0.0-SNAPSHOT
    

It’s done … import your project into your favorite IDE as a maven project, compile and install on your favorite Web Application server and enjoy!

maven jaxb plugin configuration to generate XSD schema files

Here is how to configure your project in order to generate XSD schema files from Java JAXB annotated classes

<plugin>
 <groupId>org.codehaus.mojo</groupId>
  <artifactId>jaxb2-maven-plugin</artifactId>
  <version>1.5</version>
  <executions>
   <execution>
    <goals>
     <goal>schemagen</goal>
    </goals>
    <phase>generate-sources</phase>
    <configuration>
     <outputDirectory>${project.build.directory}/schemas</outputDirectory>
     <workDirectory>${project.build.directory}/generated-sources/jaxb</workDirectory>
    <includes>
     <include>${path_to_pojo_package}/*.java</include>
    </includes>
    <transformSchemas>
     <transformSchema>
      <uri>${namespace}</uri>
      <toFile>${xsd_filename}</toFile>
     </transformSchema>
    </transformSchemas>
   </configuration>
  </execution>
 </executions>
</plugin>

This will generate an XSD file named ${xsd_filename} in the target/schemas folder.

We chose the generate-source phase in order to make the schema file available for the sources (particularly for the test sources), in conjunction with the following resources configuration to add the schema to the generated artifact:

<resources>
 <resource>
  <directory>src/main/resources</directory>
 </resource>
 <resource>
 <directory>${project.build.directory}/schemas</directory>
  <targetPath>schemas</targetPath>
 </resource>
</resources>

A Maven configuration for a Java Webstart (JNLP) application – 2

In a previous post I detailed the Maven configuration to generate a Java Webstart application using the webstart-maven-plugin along with the maven-shade-plugin (the shade plugin allows to generate auto-executable jars).

I faced some troubles when I tried to use this configuration in another application requiring access to system resources (accessing files and directories for read and write operations) and using third party trusted libraries:

When the application needs grant access system resources, you must ask for that grant through the all-permissions configuration element in the jnlp file

<security>
     <all-permissions/>
</security>

However, to do this, you must sign all the jars: the application jar and the third party jars the application needs, and generally the third party jars you are using are signed and this makes the maven-shade-plugin fail when processing the whole. Even more, if the whole application is not signed with the same certification authority, it will fail executing on the client side.

So I ended up with this webstart-maven-plugin configuration (which happens to be even simpler than the one on my previous post):

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>webstart-maven-plugin</artifactId>
 <version>1.0-beta-3</version>
 <executions>
  <execution>
  <id>package</id>
  <phase>package</phase>
  <goals>
   <goal>jnlp</goal>
  </goals>
  <configuration>
   <codebase>${jnlp.URL}</codebase>
   <jnlp>
    <mainClass>${mainClass}/mainClass>
   </jnlp>
   <pack200>true</pack200>
   <sign>
    <keystore>${jks.filPath}</keystore>
    <keypass>${jks.keyPass}</keypass>
    <storePass>${jks.storePass}</storepass>
    <alias>${jks.alias}</alias>
    <verify>false</verify>
    </sign>
    <unsignAlreadySignedJars>true</unsignAlreadySignedJars>
   </configuration>
  </execution>
 </executions>
</plugin>

Note also that there is no need to the maven-shade-plugin.

The unsignAlreadySignedJars property allows to unsign the third party libraries you are using, and signing them again with your signing configuration.

Replace in the above plugin configuration the ${jnlp.URL}, ${mainClass} and ${jks.X} parameters with yours.

Spring MVC 3.1 and Apache Tiles 2 maven archetype

Find in this post a Maven archetype for a Spring MVC 3.1 and Apache tiles 2.
The generated application is maven-based web application (.war) where the dependencies are all configured and set:

  • servlet-api 2.5
  • Apache tiles 2.2
  • Spring MVC 3.1
  • jstl 1.2
  • Java 1.6 version (this is not a constraint, I think you could downgrade the version to 1.5 without difficulties)

The application is ready to deploy on a web application server (tested on Apache tomcat 6.x and higher).

Installing and using the archetype

  1. Download the archetype from this link
  2. Install the downloaded archetype to your local repository using the following command (sorry it is not yet available from the Maven central)
    mvn install:install-file -Dfile=springmvc3.1-archetype-1.0.1.jar -DgroupId=com.michir.projects -DartifactId=springmvc3.1-archetype -Dversion=1.0.1 -Dpackaging=jar -DgeneratePom=true [-DlocalRepositoryPath=[path to your local repository]]
    
  3. Once installed on your local repository, generate a new web project using the following maven command
    mvn archetype:generate -DarchetypeGroupId=com.michir.projects -DarchetypeArtifactId=springmvc3.1-archetype -DarchetypeVersion=1.0.1 -DgroupId=com.mycompany -DartifactId=myproject -Dversion=1.0.0-SNAPSHOT
    

A new (Maven) web project is generated under the “myproject” folder (your artifactId from the maven command line). The projects comes with:

  • A spring configuration file under src/main/webapp/WEB-INF/spring-servlet.xml with an Apache tiles 2 configuration, pointing to tiles.xml tiles configuration file (see Spring MVC documentation for more View Resolvers).
  • The web application is configured (see web.xml) to map the Spring Dispatcher Servlet to *.html
  • The spring framework will scan the package com.mycompany (your groupId from the maven command line) for spring annotated controllers, see the “context:component-scan” tag in spring-servlet.xml file
  • The application comes with Page1Controller.java in the package “com.mycompany” spring controller (as an example) that maps page1.html, it is redirected to the page1.jsp view under src/main/webapp/WEB-INF/jsp/

Adding a new controller, a new view to the project

If your are not used with Spring MVC framework and Apache tiles, adding a new component may seem tedious. Here are the steps to achieve that (base on the above installation and configuration):

  1. Create a new Spring @Controller, say MayController.java in the package “com.mycompany” that maps, say “page2.html”
    package com.mycompany;
    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.RequestMapping;
    @Controller
    public class MyController {
    	@RequestMapping("/page2.*")
    	public String redirect() {
    		return "page2";
    	}
    }
    
  2. Create a “page2.jsp” file in “WEB-INF/jsp” folder, along with “page1.jsp”:
    <!-- to use spring jsp tags -->
    <%@taglib uri="http://www.springframework.org/tags/form" prefix="form"%>
    <html>
      <head>
        <title>Page 2</title>
      </head>
      <body>
        <h2>Page 2</h2>
      </body>
    </html>
    
  3. Add the “page2.jsp” definition to the “tiles.xml” file:

    ...
    <definition name="page2" extends="base.definition">
       <put-attribute name="title" value="Page 2" />
       <put-attribute name="body" value="/WEB-INF/jsp/page2.jsp" />
    </definition>
    ...
    

It is done, you can now compile/build your application, deploy on a web server and test it (oh … perhaps one last thing, add a link to your newly added page in menu.jsp along with the “page1” link like this:

   <a href="page1.html">Page 1</a><br />
   <a href="page2.html">Page 2</a><br />

Enjoy!

AspectJ and Maven configuration

Here is a maven configuration for AspectJ weaving. We use here the “codehaus” maven plugin for AOP Weaving with AspectJ 1.6.x and Java 1.6 versions.

maven dependencies

<dependencies>
...
  <dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjrt</artifactId>
    <version>1.6.11</version>
  </dependency>
...
  <dependency>
    <groupId>my-artifact-to-weave.groupId<groupId>
    <artifactId>my-artifact-to-weave.artifactId</artifactId>
    <version>my-artifact-to-weave.version</version>
  </dependency>
...
</dependencies>

maven compiler plugin configuration

In order to use annotated based pointcuts and advices definitions.

<build>
  <plugins>
    ...
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.5.1</version>
      <configuration>
        <target>1.6</target>
        <source>1.6</source>
      </configuration>
    </plugin>
    ...
  </plugins>
</build>

maven AspectJ plugin configuration

<build>
  <plugins>
    ...
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>aspectj-maven-plugin</artifactId>
      <version>1.4</version>
      <configuration>
        <weaveDependencies>
          <weaveDependency>
            <groupId>my-artifact-to-weave.groupId<groupId>
            <artifactId>my-artifact-to-weave.artifactId</artifactId>
          </weaveDependency>
        </weaveDependencies>
      </configuration>
      <executions>
        <execution>
          <id>compile</id>
          <configuration>
            <source>1.6</source>
          </configuration>
          <goals>
            <goal>compile</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
</build>