Schlagwörter: Eclipse Kommentarverlauf ein-/ausschalten | Tastaturkürzel

  • Andreas Höhmann 13:36 am Wednesday, 5. January 2011 Permalink |
    Tags: Eclipse, 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: Eclipse, 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 12:55 am Friday, 11. June 2010 Permalink |
    Tags: Eclipse, graph, jung, , , ricochet robots   

    Oberwald Rally 

    Ich habe heute ein kleines privates Projekt öffentlich zugänglich gemacht.

    Das Projekt entstand im Rahmen unseres jährlichen Männertagstreffens (wir Leipziger HTWK Mappen feiern nicht nur einen Tag sondern gleich vier). Dieses Mal waren wir halt im schönen Oberwald. Der Tag war noch jung, ein paar Bier waren auch schon geleert … also was tun. Na dann einfach Mal etwas programmieren 😀 Ziel: „Rasende Roboter“ programmieren, am besten gleich einen Algorithmus schreiben, der das Problem automatisch löst. Das Projekt beschäftigt sich also mit dem Thema „Ricochet Robots“ (im dt. Rasende Roboter). Wie ich hier bereits schon schrieb, ist es eines meiner Lieblingsspiele 🙂

    Das ganze Ding ist mittlerweile zu einem Eclipse PDE Projekt gereift … hier ein paar Screenshots …

    Random Calculator View

    Der RandomCalculator schiebt die 4 Roboter nach dem Zufallsprinzip über das Brett. Dabei kommt es ab und zu auch dazu, dass die Aufgabe (Roboter vom grünen Feld auf das rote Feld) gelöst wird 🙂

    Graph Calculator View

    Der GraphCalculator ist schon etwas „schlauer“, allerdings kann er nur den kürzesten Weg für einen Roboter berechnen.

    Den Code gibts unter https://github.com/ahoehma/oberwaldrally.

    Feedback erwünscht!

    Viel Spass beim Bot schreiben!

    😀

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

    QcMylyn 0.2.7 is out! 

    The QC Mylyn Team proudly presents the 0.2.7 Release …

    Homepage

    Changelog

    Eclipse Update Site

    We need Feedback! 😀

     
  • Andreas Höhmann 15:03 am Thursday, 26. November 2009 Permalink |
    Tags: Eclipse, , , ,   

    Concept to handle minimal and maximal tests in a maven project 

    In real world applications we have all too often external dependencies in test cases. Sometimes theses third party are not always available (i.e. remote webservices).

    For continuous integration I want check a minimal set of tests but for my local development i want check a maximal set of tests. I want run my tests on command line (via maven) and in eclipse (via testng-plugin).

    Here is my idea to do that …

    My project super pom defines 2 profiles:

    • test-min
      1. active by default
      2. exclude testng groups (online-tests, thirdparty-tests,…)
    • test-max
      1. run a defined testng suite
      2. the suite defines a maximal set of test (all testng groups)
    <profiles>
      <profile>
        <id>test-min</id>
        <activation>
          <activeByDefault>true</activeByDefault>
        </activation>
        <build>
          <plugins>
            <plugin>
              <artifactId>maven-surefire-plugin</artifactId>
              <inherited>true</inherited>
              <configuration>
                <excludedGroups>${excludedTestGroups}</excludedGroups>
              </configuration>
            </plugin>
          </plugins>
        </build>
      </profile>
      <profile>
        <id>test-max</id>
        <build>
          <plugins>
            <plugin>
              <artifactId>maven-surefire-plugin</artifactId>
              <inherited>true</inherited>
              <configuration>
                <suiteXmlFiles>
                  ${basedir}/src/test/resources/Testsuite.xml
                </suiteXmlFiles>
              </configuration>
            </plugin>
          </plugins>
        </build>
      </profile>
    </profiles>
    <properties>
      <excludedTestGroups>online,integration,thirdparty</excludedTestGroups>
    </properties>
    

    Each subproject must define a testng src/test/resources/Testsuite.xml:

    <!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
    <suite name="TestSuite for Foobar">
      <test name="Online Tests">
        <packages>
          <package name="de.foobar.*" />
        </packages>
        <groups>
          <run>
            <include name="online" />
          </run>
        </groups>
      </test>
      <test name="Integration Tests">
        <packages>
          <package name="de.foobar.*" />
        </packages>
        <groups>
          <run>
            <include name="integration" />
          </run>
        </groups>
      </test>
      <test name="Thirdparty Tests">
        <packages>
          <package name="de.foobar.*" />
        </packages>
        <groups>
          <run>
            <include name="thirdparty" />
          </run>
        </groups>
      </test>
      <!-- Each project can define MORE groups: i.e. "interactive" -->
      <test name="Other Tests">
        <packages>
          <package name="de.foobar.*" />
        </packages>
        <groups>
          <run>
            <exclude name="online" />
            <exclude name="integration" />
            <exclude name="thirdparty" />
            <!-- Each project can define MORE groups: i.e. "interactive" -->
          </run>
        </groups>
      </test>
    </suite>
    

    If the sub project defines more exclude groups (i.e. a additional „interactive“ group) then the pom must overwrite the excludedTestGroups property:

    <properties>
      <excludedTestGroups>online,integration,thirdparty,interactive</excludedTestGroups>
    </properties>
    

    To check the correct configuration of the two profiles we can use help:effective-pom:

    mvn -Ptest-min help:effective-pom | less

    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
        <excludedGroups>online,integration,thirdparty,interactive</excludedGroups>
      </configuration>
    </plugin>
    

    mvn -Ptest-max help:effective-pom | less

    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
        <suiteXmlFiles>
          <suiteXmlFile>d:\foobar\src/test/resources/Testsuite.xml</suiteXmlFile>
        </suiteXmlFiles>
      </configuration>
    </plugin>
    

    Now I can run min/max tests for each project which depend on the above super-pom. The test-min is the default profile and would be used on the continuous integration system (i.e. TeamCity).

    Try it 🙂

     
    • Thomas Wabner 10:09 am Dienstag, 31. Januar 2012 Permalink | Zum Antworten anmelden

      Short info … the current 2.11 version of the surefire plugin contains a bug with the „excludeGroups“ rule … you need to wait for 2.12 or just use 2.10.

  • Andreas Höhmann 18:08 am Friday, 13. November 2009 Permalink |
    Tags: Eclipse, , osgi, rcp,   

    Build eclipse applications with maven 3 

    The  tool chain for building eclipse based applications with maven becomes better and better.

    Read here.

    I know 2 projects using maven to build eclipse plugins:

    Which project are there else?

     
  • Andreas Höhmann 9:54 am Wednesday, 28. October 2009 Permalink |
    Tags: com4j, Eclipse, , , 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">
          <modelVersion>4.0.0</modelVersion>
          <groupId>otaclient</groupId>
          <artifactId>otaclient</artifactId>
          <version>9.1.0.4372</version>
          <dependencies>
            <dependency>
              <groupId>org.jvnet.com4j</groupId>
              <artifactId>com4j</artifactId>
              <version>20080107</version>
            </dependency>
          </dependencies>
          <build>
            <plugins>
              <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                  <source>1.5</source>
                  <target>1.5</target>
                </configuration>
              </plugin>
              <plugin>
                <groupId>org.jvnet.com4j</groupId>
                <artifactId>maven-com4j-plugin</artifactId>
                <executions>
                  <execution>
                    <id>gen-java-bridge</id>
                    <goals>
                      <goal>gen</goal>
                    </goals>
                    <configuration>
                      <file>src/qc/OTAClient.dll</file>
                      <package>com.mercury.qualitycenter.otaclient</package>
                    </configuration>
                  </execution>
                </executions>
              </plugin>
            </plugins>
          </build>
        </project>
    

    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-9.1.0.4372.jar. Copy this jar into qctools4j/lib/com.mercury.qualitycenter.otaclient-9.2.jar and rebuild qctools4j. That’s all 🙂

    qcmylyn_otaclient

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

    qcmylyn_qctools4j

    Try it 🙂

     
  • Andreas Höhmann 13:41 am Monday, 24. August 2009 Permalink |
    Tags: code template, Eclipse, 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() {
        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“:

    maven_version_editortemplate

    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:

    maven_version_codetemplate

    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):

    maven_version_test_without_m2eclipse

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

    maven_version_test_with_m2eclipse

    If anyone need the plugin … leave a comment.

     
  • Andreas Höhmann 18:50 am Wednesday, 22. July 2009 Permalink |
    Tags: EclEmma, Eclipse, 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:

    eclipse3.5

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

     
  • Andreas Höhmann 11:13 am Monday, 8. June 2009 Permalink |
    Tags: Eclipse, , , Repository   

    Nexus Pro verwaltet Eclipse-Repositories 

    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

     
c
Neuen Beitrag erstellen
j
nächster Beitrag/nächster Kommentar
k
vorheriger Beitrag/vorheriger Kommentar
r
Antworten
e
Bearbeiten
o
zeige/verstecke Kommentare
t
Zum Anfang gehen
l
zum Login
h
Zeige/Verberge Hilfe
Shift + ESC
Abbrechen