Based on waffel’s blog i wrote a eclipse plugin which provides the current artifact-version of a maven-project to the eclipse editor-templates. Waffel want to add the current plugin id/version to the @since field for class comments, i want to add the current version of my maven-eclipse-project. Let me explain my solution.

It’s easy to add a new template-variable to eclipse, you can read this. Based on  org.eclipse.jface.text.templates.TemplateVariableResolver we can write a MavenVersionResolver:

/**
 * Resolver to resolve variable <code>pomVersion</code>.
 *
 * @author hoehmann
 * @since 1.0.0
 */
public class MavenVersionResolver extends TemplateVariableResolver {

  public MavenVersionResolver() {
    super();
  }

  private String getMavenVersion(final IProject project) {
    if (project == null) {
      throw new IllegalArgumentException("Missing project"); //$NON-NLS-1$
    }
    String result = ""; //$NON-NLS-1$
    try {
      if (project.hasNature(IMavenConstants.NATURE_ID)) {
        final MavenProjectManager projectManager = MavenPlugin.getDefault()
            .getMavenProjectManager();
        final IMavenProjectFacade projectFacade = projectManager.create(
            project, new NullProgressMonitor());
        if (projectFacade != null) {
          final ArtifactKey mavenProject = projectFacade.getArtifactKey();
          if (mavenProject != null) {
            result = mavenProject.getVersion();
            // remove snapshot-indicator
            final int index = result.lastIndexOf("-SNAPSHOT"); //$NON-NLS-1$
            if (index != -1) {
              result = result.substring(0, index);
            }
          }
        }
      }
    } catch (final CoreException ex) {
      MavenLogger.log(ex);
    }
    return result;
  }

  /**
   * {@inheritDoc}
   */
  @Override
  protected String resolve(final TemplateContext context) {
    // TODO better way to get the project?!
    return getMavenVersion(((CodeTemplateContext) context).getJavaProject()
        .getProject());
  }
}

With the MavenProjectManager from m2eclipse we can create a IMavenProjectFacade, this facade returns the ArtifactKey and this key have the version. If the version is a snapshot-version we can cut this trailing string off and the result is the (next) version for our maven-project (for me it doesn’t make sense to add the snapshot-version into a @since comment because the release-version should be documented in the sourcecode).

Maybe the check for the “m2eclipse”-nature is not necessary:

if (project.hasNature(IMavenConstants.NATURE_ID)) {....}

I tried without the nature-check and it works. The project must contain a “pom.xml” to get a IMavenProjectFacade.

This was the first part of the solution. The placeholder “pom_version” will be available for all editor-templates in the “java-context”:

Waffel described already a solution (a workaround) to use a editor-template-resolver in the code-templates. He registered a IStartup class which copies his own BundleIdResolver/BundleVersionResolver into the (internal) code-template-context-registry of the Eclipse-Java-Plugin. For waffel this was fine because he doesn’t register his resolvers as editor-template-resolvers. I want use my MavenVersionResolver in all java-templates and in the code-templates.

And i don’t want create a new instance of the resolver, i want reuse the extension-point-configured resolver. So i have only one place to define my resolver (type = ‘pom_version’, localized name, localized description, class etc.).

I found a other way to register the resolver

1. i search my MavenVersionResolver in the registered editor-templates (java-context)
2. if i found one, i add this reference to the (internal) code-template-registry

/**
 * Currently it's not possible to provide more variables for
 * <tt>java-code-templates</tt>, we can only add more <tt>editor-templates</tt>
 * via extension-point.
 *
 * <p>
 * This {@link IStartup} is a workaround to register our
 * {@link MavenVersionResolver} for <tt>java-code-templates</tt> too.
 * </p>
 *
 * @author hoehmann
 * @since 1.0.0
 */
public class RegisterResolvers implements IStartup {

  private static final String JAVA_PLUGIN_ID = "org.eclipse.jdt.ui"; //$NON-NLS-1$

  /**
   * Add our resolver to each registered code-template-context.
   *
   * @param javaPlugin
   *          must not be <code>null</code>
   * @param mavenVersionResolver
   *          must not be <code>null</code>
   */
  private void addMavenVersionResolver(final JavaPlugin javaPlugin,
      final MavenVersionResolver mavenVersionResolver) {
    Assert.isNotNull(javaPlugin);
    final ContextTypeRegistry codeTemplateContextRegistry = javaPlugin
        .getCodeTemplateContextRegistry();
    Assert.isNotNull(codeTemplateContextRegistry);
    final Iterator ctIter = codeTemplateContextRegistry.contextTypes();
    while (ctIter.hasNext()) {
      final TemplateContextType contextType = (TemplateContextType) ctIter
          .next();
      contextType.addResolver(mavenVersionResolver);
    }
  }

  /**
   * {@inheritDoc}
   */
  public void earlyStartup() {
    // check if plug-in org.eclipse.jdt.ui is final already active
    final Bundle bundle = Platform.getBundle(JAVA_PLUGIN_ID);
    if (bundle != null && bundle.getState() == Bundle.ACTIVE) {
      registerResolvers();
    } else {
      // register listener to final get informed, when plug-in final becomes
      // active
      final BundleContext bundleContext = Activator.getDefault().getBundle()
          .getBundleContext();
      bundleContext.addBundleListener(new BundleListener() {
        public void bundleChanged(final BundleEvent pEvent) {
          final Bundle eventBundle = pEvent.getBundle();
          if (!eventBundle.getSymbolicName().equals(JAVA_PLUGIN_ID)) {
            // ignore other plugins
            return;
          }
          if (eventBundle.getState() == Bundle.ACTIVE) {
            registerResolvers();
            bundleContext.removeBundleListener(this);
          }
        }
      });
    }
  }

  /**
   * Try to find our {@link MavenVersionResolver} in the java-plugin
   * template-context-registry.
   *
   * @param javaPlugin
   *          must not be <code>null</code>
   * @return
   */
  private MavenVersionResolver getMavenVersionResolver(
      final JavaPlugin javaPlugin) {
    Assert.isNotNull(javaPlugin);
    final ContextTypeRegistry contextRegistry = javaPlugin
        .getTemplateContextRegistry();
    Assert.isNotNull(contextRegistry);
    final TemplateContextType javaContextType = contextRegistry
        .getContextType(JavaContextType.ID_ALL);
    Assert.isNotNull(javaContextType);
    final Iterator<TemplateVariableResolver> resolvers = javaContextType
        .resolvers();
    MavenVersionResolver mavenVersionResolver = null;
    while (resolvers.hasNext()) {
      final TemplateVariableResolver resolver = resolvers.next();
      if (resolver instanceof MavenVersionResolver) {
        mavenVersionResolver = (MavenVersionResolver) resolver;
        break;
      }
    }
    return mavenVersionResolver;
  }

  /**
   * First find the maven-version-resolver from the registered resolvers.
   */
  private void registerResolvers() {
    final JavaPlugin javaPlugin = JavaPlugin.getDefault();
    if (javaPlugin == null) {
      throw new IllegalStateException(String.format(
          "Expected plugin '%s' is not available", JAVA_PLUGIN_ID));
    }
    final MavenVersionResolver mavenVersionResolver = getMavenVersionResolver(javaPlugin);
    if (mavenVersionResolver != null) {
      addMavenVersionResolver(javaPlugin, mavenVersionResolver);
    }
  }
}

Now its possible to use “pom_version” in code-templates too:

Now the final test  …  create a “normal” java-project, create a new class. The javadoc will not contain a version (the project doesn’t have a maven-nature):

If the project is a “real” maven project the version will be available:

If anyone need the plugin … leave a comment.

With maven it’s possible to deploy the current version of your webapplication (<packaging>war</packaging>) with one command!

mvn clean package tomcat:deploy-only

All we have to to is to define the tomcat-maven-plugin:

...
<packaging>war</packaging>
...
<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>tomcat-maven-plugin</artifactId>
 <configuration>
 <url>http://server[:port]/manager</url>
<path>/${project.build.finalName}</path>
 <update>true</update>
<server>tomcat_xyz</server>
 </configuration>
 </plugin>

You have to define username/password in your settings.xml:

<?xml version="1.0" encoding="UTF-8"?>
<settings 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/xsd/settings-1.0.0.xsd">

<servers>
<server>
<id>tomcat_xyz</id>
<username>admin</username>
<password>123geheim</password>
</server>
</servers>

</settings>

Check the tomcat-user.xml:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
 <role rolename="manager"/>
 <role rolename="admin"/>
 <user username="admin" password="123geheim" roles="admin,manager"/>
</tomcat-users>

If you  run the maven command you will see:

[INFO] [tomcat:deploy-only {execution: default-cli}]
[INFO] Deploying war to http://server:8080/foobar-1.0.0-SNAPSHOT-B20090710  
[INFO] OK - Deployed application at context path /foobar-1.0.0-SNAPSHOT-B20090710
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

To get the version and a buildnumber in the context-path you must define the finalName and you must use a “buildnumber-plugin”, e.g.  buildnumber-maven-plugin or maven-timestamp-plugin:

<build>
 <finalName>foobar-${project.version}-B${buildNumber}</finalName>
 </build>

<plugins>
<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>buildnumber-maven-plugin</artifactId>
 <executions>
 <execution>
 <id>create-buildnumber</id>
<phase>validate</phase>
 <goals>
 <goal>create</goal>
 </goals>
 </execution>
 </executions>
 <configuration>
 <doUpdate>false</doUpdate>
 <doCheck>false</doCheck>
 <format>{0,date,yyyyMMdd}</format>
 <items>
 <item>timestamp</item>
 </items>
 <buildNumberPropertyName>buildNumber</buildNumberPropertyName>
</configuration>
 </plugin>

<plugin>
 <groupId>com.keyboardsamurais.maven</groupId>
 <artifactId>maven-timestamp-plugin</artifactId>
 <executions>
 <execution>
 <id>create-buildnumber</id>
 <goals>
 <goal>create</goal>
 </goals>
 <configuration>
<propertyName>buildNumber</propertyName>
 <timestampPattern>yyyyMMdd</timestampPattern>
 </configuration>
 </execution>
 </executions>
 </plugin>

</plugins>

Mit Hilfe von Nexus-Pro (Version 1.3.2) ist es möglich Eclipse-Plugin-Repositories zu verwalten.

Damit wird es möglich für ein Entwicklungsteam eine Liste von Plugin-Repositories zentral zu verwalten. Alle Entwickler stellen in ihrem Eclipse Update Manager nur noch dieses eine Repository (Nexus) ein und fertig

Vorteile:
- externer Netzwerktraffic wird reduziert
- Thema Sicherheit, Entwickler müssen nicht unbedingt ins Internet (Proxy etc.)
- man sieht zentral welche Plugins, in welchen Versionen verwendet werden

Kurzes Video hier: http://vimeo.com/4102464

As you might know already, Hibernate supports logging for sql-statements. Your Spring-configuration (e.g. spring-database.xml) must contain this:

<bean id="entityManagerFactory"
 class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceUnitName" value="logging-test" />
<property name="jpaVendorAdapter">
 <bean>
<property name="showSql" value="true" />
<property name="generateDdl" value="true" />
<property name="databasePlatform" value="${jpa.hibernate.dialect}" />
 </bean>
 </property>
<property name="jpaProperties" value="hibernate.dialect=${jpa.hibernate.dialect}" />
 </bean>

With showSql=true hibernate will show you logmessages like this:

Hibernate:
   delete
   from
      SoftwareCategory_SoftwareCategory
   where
      SoftwareCategory_id=?
Hibernate:
   update
      SoftwareCategory
   set
      concurrentVersion=?,
      CATEGORY_NAME=?,
      PARENT_ID=?
   where
      id=?
      and concurrentVersion=?
Hibernate:
   insert
   into
      SoftwareCategory_SoftwareCategory
      (SoftwareCategory_id, POSITION, children_id)
   values
      (?, ?, ?)

To see the values and not the placeholders (?) you must define the loglevel trace for hibernate-types in the log4j.xml:

<category name="org.hibernate.type">
<priority value="trace" />
 </category>

Then you will see logmessages like this:

Hibernate:
   insert
   into
      SoftwareCategory_SoftwareCategory
      (SoftwareCategory_id, POSITION, children_id)
   values
      (?, ?, ?)
NullableType:151 - binding '68' to parameter: 1
NullableType:151 - binding '0' to parameter: 2
NullableType:151 - binding '69' to parameter: 3

Not bad but there is a better way for this

Yesterday i found the project JDBCLogger.  They have implemented a “JDBC-Proxy” with logging support. Its Maven-ready and comes with a easy Spring-integration. So how can we use this cool stuff … it is so easy:

1. Define the JDBCLogger dependencies in the pom.xml:

<dependencies>
<dependency>
 <groupId>net.sourceforge.jdbclogger</groupId>
 <artifactId>jdbclogger-core</artifactId>
 <version>0.7-SNAPSHOT</version>
 </dependency>
 <dependency>
 <groupId>net.sourceforge.jdbclogger</groupId>
 <artifactId>jdbclogger-spring</artifactId>
 <version>0.7-SNAPSHOT</version>
 </dependency>
 </dependencies>

The informations from the installation-guide on the project-site is a little too old, so the maven-repository http://jdbclogger.sourceforge.net/m2-repo/ doesn’t exists. No problem we can build jdbclogger-core and jdbclogger-spring by ourself (read more). The simplest way to build the two artifacts is:

• checkout from  svn
• edit master-pom, comment out all modules, leave only core and spring active
• run mvn clean install from root-dir

2. Change your Spring-configuration, switch showSql off and add the following bean:

<bean id="jdbcLoggerConfig"
 class="net.sourceforge.jdbclogger.spring.JdbcLoggerBeanPostProcessor">
<property name="enabled" value="true" />
<property name="dataSourceConfigurations">
	<list>
 <bean class="net.sourceforge.jdbclogger.spring.JdbcLoggerDataSourceConfiguration">
<property name="dataSourceBeanName" value="dataSource" />
<property name="driverClassNamePropertyName" value="driverClassName" />
 </bean>
 </list>
 </property>
<property name="targetDriverClassNames">
	<list>
 <value>${jpa.driver}</value>
 </list>
 </property>
 </bean>

3.  Activate logging in the log4j.xml:

<category name="net.sourceforge.jdbclogger">
<priority value="debug" />
 </category>
<category name="net.sourceforge.jdbclogger.spring">
<priority value="error" />
 </category>

Thats it Now you will see logmessages like this:

JdbcLoggerDriver:65 – Wrapper ‘net.sourceforge.jdbclogger.JdbcLoggerDriver’ successfully registed for driver ‘com.mysql.jdbc.Driver’
PreparedStatementWrapper:156 – Prepared Statement : select softwareca0_.id as id0_, softwareca0_.concurrentVersion as concurre2_0_, softwareca0_.CATEGORY_NAME as CATEGORY3_0_, softwareca0_.PARENT_ID as PARENT4_0_ from SoftwareCategory softwareca0_ where softwareca0_.PARENT_ID is null
StatementWrapper:45 – Statement : delete from softwarecategory_softwareobject
PreparedStatementWrapper:156 – Prepared Statement : insert into SoftwareCategory_SoftwareCategory (SoftwareCategory_id, POSITION, children_id) values (‘92′, ‘3′, ‘96′)

In huge multi-module-projects the maven-release-process might have a long running time because there is a lot of site-content to generate and to deployed (Of course this depends on the used report-plugins, i.e. javadoc, findbugs,pmd, dashboard etc.)

I noticed that the upload of the generated javadoc etc. uses a big amount of the deployment time. So how we can speedup this part of the deployment?

We can deploy the generated site in a local directory and after the successful release we can upload the whole directory to the server, i.e. zip the content and unpack on the server, or use a smb-shared-directory … then the site-upload is much faster than with site:deploy and webdav.

<?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>

<distributionManagement>
 <site>
 <id>site</id>
 <url>${site.distribution.url}/</url>
 </site>
<distributionManagement>
<profiles>
<profile>
 <id>release</id>
<properties>
 <site.distribution.url>file://D:/SITE-RELEASE/</site.distribution.url>
 <site.url>http://site-server/releases/</site.url>
 </properties>
 </profile>
</profiles>
<properties>
 <site.url>http://site-server/snapshots/</site.url>
 <site.distribution.url>dav:${site.url}</site.distribution.url>
</properties>

</project>

Try it