Aktualisierungen Januar, 2011 Kommentarverlauf ein-/ausschalten | Tastaturkürzel

  • Andreas Höhmann 13:36 am Wednesday, 5. January 2011 Permalink |
    Tags: , JDT, Quickfix   

    Eclipse JDT Quickfix : remove method 

    I hacked  a little JDT Quickfix to resolve a compilation error „missing method“ … see Bug 33465.

    The usecase for this quickfix is the following:

    1.  I remove a Property from a Entity class

    2.  I have a lot of Testclasses where the setter is used

    3.  I wan’t go into each Testclass and remove the compile error by hand

    4. I want use a quickfix „remove usage of missing method“

    You can find the code at https://github.com/ahoehma/de.ahoehma.jdt

    Please check / use / change the code 😀

    This article was very helpfull :  http://it-republik.de/jaxenter/artikel/Eclipse-JDT-um-eigene-Quickfixes-erweitern-1136.html

  • Andreas Höhmann 8:57 am Thursday, 24. June 2010 Permalink |
    Tags: , editor templates,   

    Mylyn 3.4 is out and I provided a feature :-D 

    Juhu … Version 3.4 of Mylyn is out …

    An overview of the New & Noteworthy features is at: http://eclipse.org/mylyn/new/

    For this version I provided a little feature … „Editor-Template for Active Task

    Mylyn 3.4 active task editor template

    Try it out! 😀

  • Andreas Höhmann 9:47 am Friday, 4. December 2009 Permalink |
    Tags: , ,   

    QcMylyn 0.2.7 is out! 

    The QC Mylyn Team proudly presents the 0.2.7 Release …



    Eclipse Update Site

    We need Feedback! 😀

  • Andreas Höhmann 9:54 am Wednesday, 28. October 2009 Permalink |
    Tags: com4j, , , , qc,   

    Quality Center Mylyn Integration 

    There is a interesting project at sourceforge called qcMylyn.  The projects aims to provide a Mylyn connector for Quality Center. Support Eclipse 3.4.2, 3.5, Mylyn 3.0.5+.

    I tried the released version 0.2.4 but it didn’t work because at work we are using an older version of QualityCenter (9.1). But this was no big problem I have the sourcecode (OS rocks) and I’m a programmer 😉

    I found out that a other project called QcTools4J contains the java code for manipulation a QC system. They using a com4j bridge to bind QC’s otaclient.dll.

    If you have trouble with a older/newer version of QC you have to update the qctools4j.

    You find a short tutorial how to update qctools4j here. (read this first) … then you will come to the point where you want create a new otaclient.jar from you local otaclient.dll. Here is my simple solution for that.

    I create my own otaclient maven project with the following pom:

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

    I using the maven-com4j-plugin to generate the java layer for otaclient.

    All you have to do is to extract your „qc client package“ (could be download from every qc server page) into src/qc and start mvn clean package.

    Then target will contain a otaclient- Copy this jar into qctools4j/lib/com.mercury.qualitycenter.otaclient-9.2.jar and rebuild qctools4j. That’s all 🙂


    Then copy the qctools4j.jar into org.tszadel.qctools and rebuild the whole eclipse feature.


    Try it 🙂

  • Andreas Höhmann 13:41 am Monday, 24. August 2009 Permalink |
    Tags: code template, , extension point, , m2eclipse, , , , pom, version   

    Use Maven Artifact Version in Eclipse Code Templates 

    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() {
      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()
            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) {
        return result;
       * {@inheritDoc}
      protected String resolve(final TemplateContext context) {
        // TODO better way to get the project?!
        return getMavenVersion(((CodeTemplateContext) context).getJavaProject()

    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) {
        final ContextTypeRegistry codeTemplateContextRegistry = javaPlugin
        final Iterator ctIter = codeTemplateContextRegistry.contextTypes();
        while (ctIter.hasNext()) {
          final TemplateContextType contextType = (TemplateContextType) ctIter
       * {@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) {
        } else {
          // register listener to final get informed, when plug-in final becomes
          // active
          final BundleContext bundleContext = Activator.getDefault().getBundle()
          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
              if (eventBundle.getState() == Bundle.ACTIVE) {
       * 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) {
        final ContextTypeRegistry contextRegistry = javaPlugin
        final TemplateContextType javaContextType = contextRegistry
        final Iterator<TemplateVariableResolver> resolvers = javaContextType
        MavenVersionResolver mavenVersionResolver = null;
        while (resolvers.hasNext()) {
          final TemplateVariableResolver resolver = resolvers.next();
          if (resolver instanceof MavenVersionResolver) {
            mavenVersionResolver = (MavenVersionResolver) resolver;
        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.

  • Andreas Höhmann 18:50 am Wednesday, 22. July 2009 Permalink |
    Tags: EclEmma, , FindBugs, JBoss Tools, , MoreUnit, , PropEdit, Spring-IDE, , WTP   

    My Eclipse Plugin List 

    Today i updated my Eclipse 3.5 M7 to the final 3.5. Here are my plugin list:


    • PropEdit – nice Propertyeditor which can handle UTF-8 correctly
    • Spring-IDE – Beansearch, Contexteditor with content assistant
    • FindBugs – Check your code for bugs
    • WTP – of course for a web developer 😉
    • Subversive – for SVN integration
    • JBoss Tools – nice XHTML (facelets) editor, web.xml editor, faces-config editor and more
    • m2Eclipse – cool maven integration
    • EclEmma – code coverage
    • TeamCity – continues integration platform
    • MoreUnit – jump from Code to Unittest, create new Test if not exists
    • TestNG – integration for these unittests

    What are your prefered plugins?

Neuen Beitrag erstellen
nächster Beitrag/nächster Kommentar
vorheriger Beitrag/vorheriger Kommentar
zeige/verstecke Kommentare
Zum Anfang gehen
zum Login
Zeige/Verberge Hilfe
Shift + ESC