waffel’s Weblog

November 18, 2010

disable maven enforcer rule

Filed under: software — Thomas Wabner @ 6:33 nachmittags
Tags: , , , ,

Apache maven enforcer rules are very useful in large projects. A common usage of such enforcer rules is to define them in a central point like a project parent pom.xml. For example following enforcer definition can be set in a pom parent:

package-parent pom.xml:

...
<plugin>
  <artifactId>maven-enforcer-plugin</artifactId>
     <executions>
       <execution>
         <id>enforce-java-1_4</id>
         <goals>
           <goal>enforce</goal>
         </goals>
         <configuration>
           <rules>
             <requireProperty>
                <property>java.compiler.version</property>
                <regex>1\.4</regex>
                <regexMessage>You must compile with Java 1.4, as long our servers run in old NetWeaver!</regexMessage>
              </requireProperty>
            </rules>
            <fail>true</fail>
         </configuration>
      </execution>
    </executions>
</plugin>
...

This enforcer rule should ensure that all projects, which using the parent POM using a Java 1.4 compiler.

Often such parent pom defines many other useful properties and settings for projects. If you want to use these definition and ONLY want to disable the enforcer rule you can simple do follow “trick”:

...
<parent>
  <groupId>org.waffel</groupId>
  <artifactId>package-parent</artifactId>
  <version>1.1</version>
</parent>

<build>
   <plugins>
     <!-- we need to overide the enforcer rules here because we have java 1.6 and not the  old 1.4 -->
      <plugin>
        <artifactId>maven-enforcer-plugin</artifactId>
        <executions>
          <execution>
            <id>enforce-java-1_4</id>
            <phase>none</phase>
          </execution>
        </executions>
      </plugin>
   </plugins>
</build>
...

I use the same approach here as described in my article how to diable a inherited maven plugin.

September 7, 2010

using ScribeFire to create faster my blog entries

Filed under: Blogroll — Thomas Wabner @ 4:51 nachmittags
Tags: , , ,

An articte on Heise shows me the cool Firefox plugin called ScribeFire which can be used to write Blogentries in Firefox with a much better Wysiwyg Editor than the default provided by wordpress.

For sure, ScribeFire supports many blog frameworks and has some cool features.

I love this plugin and hope I’am now able to blog more than the last month’s

Februar 16, 2010

howto disable inherited maven plugin

Filed under: software — Thomas Wabner @ 3:43 nachmittags
Tags: , , , ,

We using in our department a big hierarchy of maven parents (like the apache community does). Some of these parents define useful plugins.

If I want to use the parents (and often this is a good idea, because the parents defining for example version informations for my dependencies), but I do not want to have a specific plugin invoked while I’am using maven, I can simple disable the plugin with follow configuration in my pom.xml:

...
<build>
  <plugins>
     <plugin>
        <artifactId>thePluginArtifact</artifactId>
        <groupId>thePluginGroup</groupId>
        <executions>
           <execution>
              <id>the-execution-id</id>
              <phase>none</phase>
           </execution>
        </executions>
     </plugin>
  </plugins>
</build>
...

The trick how to disable a plugin is to set the phase of the plugin to none.

August 21, 2009

use your own variable in eclipse code templates

Filed under: java — Thomas Wabner @ 2:08 nachmittags
Tags: , , ,

On my work we develop eclipse plugins and want to add the current bundle id and bundle version to the since field for class comments. There are not much examples around this problem (we have searched google and eclipse help) so let me explain how you can achive this.

For example we want to define follow code template:

/**
 * @author ${user}
 *
 * ${tags}
 * @since ${bundleId} ${bundleVersion}
 */

The bundleId and bundleVersion variable are not provided by the standard code template variables. Now we have to find out how we can achive this problem.

First of all you need to develop your own eclipse plugin which should provide such feature. The new plugin requires follow dependencies:

  • org.eclipse.core.resources;bundle-version=”3.5.0″,
  • org.eclipse.ui;bundle-version=”3.5.0″,
  • org.eclipse.jface.text;bundle-version=”3.5.0″,
  • org.eclipse.jdt.core;bundle-version=”3.5.0″,
  • org.eclipse.jdt.ui;bundle-version=”3.5.0″,
  • org.eclipse.core.runtime;bundle-version=”3.5.0″,
  • org.eclipse.pde.core;bundle-version=”3.5.0″

The PDE dependency is needed to get the current bundle id and the bundle version. If you need other features (for example a maven project version) you have depend on other plugins. But in this example I’ll show you how to add bundle id and bundle version as extra variable for the eclipse code templates.

Next you have to create a extention to register your own variable resolver at startup. The variable resolvers are the heart of the plugin because they providing new variables for the code templates to be used and resolving the content if you use the code template.

plugin.xml:

< ?xml version="1.0" encoding="UTF-8"?>
< ?eclipse version="3.4"?>
<plugin>
   <extension point="org.eclipse.ui.startup">
      <startup class="yourplugin.eclipse.javadoc.internal.RegisterResolvers">
      </startup>
   </extension>
</plugin>

The RegisterResolvers class implements the IStartup interface from eclipse. This class registers the variable resolvers to the code template context. This is required to have the variables available in the code templates from eclipse.

RegisterResolver:

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

/**
   * 
   * Internal method to register resolvers with all context types.
   * 
   */
  private void registerResolvers() {
    final ContextTypeRegistry codeTemplateContextRegistry = JavaPlugin.getDefault().getCodeTemplateContextRegistry();
    final Iterator ctIter = codeTemplateContextRegistry.contextTypes();
    while (ctIter.hasNext()) {
      final TemplateContextType contextType = (TemplateContextType) ctIter.next();
      contextType.addResolver(new BundleIdResolver());
      contextType.addResolver(new BundleVersionResolver());

    }
  }

The bundleIdResolver extends the TemplateVariableResolver and defines (in the default constructor) the variable name which can be used later in the code template, a description and overrides the resolve method.

The resolve method checks if the current project is a plugin project and if so returns the bundle id from the project.

public class BundleIdResolver extends TemplateVariableResolver {
  /**
   * 
   * Constructs a new <code>BundleIdResolver</code>.
   * 
   */
  public BundleIdResolver() {
    super("bundleId", "id of the bundle containing the current compilation unit");
  }

  /**
   * 
   * {@inheritDoc}
   * 
   * @see TemplateVariableResolver#resolve(org.eclipse.jface.text.templates.TemplateContext)
   * 
   */
  @Override
  protected String resolve(final TemplateContext pContext) {
    final CodeTemplateContext context = (CodeTemplateContext) pContext;
    final IPluginModelBase pluginModelBase = PluginRegistry.findModel(context.getJavaProject().getProject());
    if (pluginModelBase == null) {
      return null;
    }
    return pluginModelBase.getBundleDescription().getSymbolicName();
  }
}

Now you can come up with the question why not you can use the standard eclipse extention point mechanism and create your own context.

Well, we want to extend the java context but the current eclipse implementation doe’s not provide such functionality. For sure if you want to have your own context you can do this with the standard extention point mechanism (as the Ant example). There is a small example about the eclipse editor templates.

Thanks to my colleague Marco Lehmann for the complete solution.

The Rubric Theme. Bloggen Sie auf WordPress.com.

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 28 Followern an