Just like NCrunch, it executes your code while you type. But instead of test outcomes, it focusses on the details of the code execution and provides invaluable insight into the contents of variables and even the control flow as you type. You can even drag a slider to see different iterations in loops. All you need is a starting point like a static method, a test method or any method where the parent type can be instantiated with some generic defaults.

This short video (~6 minutes) gives a great first impression so far:

I might take a look at the free 30 day trial as soon as I am back in Visual Studio.

<#= new CodeGenerator().Generate() #>

Next comes the question of how to implement the generator. StringBuilder? Come on, there must be a better way. I checked in another library that I knew was using code generation. Then I saw that the library was using CodeDOM. For my simple needs, I decided that this would be sufficient for the time being (and efficient, since I didn’t want to spend too much time there).

But then I started to wonder. Will CodeDOM still work with the new .NET Core?

The answer was no.

The linked StackOverflow question already includes the “replacement” of CodeDOM (CodeDOM is referred to as some precursor to part of what Roslyn does): The “new” Roslyn compiler platform (which has been around for a while by now). More specifically, the SyntaxFactory that comes with Roslyn.

The only draw-back I see immediately: The code that uses the SyntaxFactory seems a lot more verbose than the CodeDOM API. On the plus side, the Roslyn way should be superior to CodeDOM regarding features and support for language constructs.

There are already articles available for generating code with Roslyn, so I will leave the details to the interested reader.

Please see the MDSD report 2010 (sorry, only in German) for details on the results.

Do you make use of MDSD techniques?

package com.martinklinke.eclipse.jfreechart.demo.views;

import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.ui.part.ViewPart;
import org.jfree.chart.JFreeChart;
import org.jfree.chart.plot.MeterPlot;
import org.jfree.data.general.DefaultValueDataset;
import org.jfree.experimental.chart.swt.ChartComposite;

/**
* @author martin
*
*/
public class MeterChartView extends ViewPart {
   public static final String ID = "com.martinklinke.eclipse.jfreechart.demo.views.MeterChartView";

   public void createPartControl(Composite parent) {
      JFreeChart chart = createChart();
      final ChartComposite frame = new ChartComposite(parent, SWT.NONE, chart, true);
   }

   public void setFocus() {
   }

   /**
    * Creates the Chart based on a dataset
    */
   private JFreeChart createChart() {
      DefaultValueDataset data = new DefaultValueDataset(20.0);
      MeterPlot plot = new MeterPlot(data);
      JFreeChart chart = new JFreeChart("Meter Chart",
      JFreeChart.DEFAULT_TITLE_FONT, plot, false);
      plot.setNoDataMessage("No data available");
      return chart;
   }
}

The result should look like the following screenshot:

JFreeChart Speedometer in Eclipse View

Of course, the MeterPlot can be further customized by calling the plot.setXXX(…) methods. However, this exercise is left to the willing reader ;)

The <workspace>/.metadata/.log file contained the following error message many times:

!ENTRY org.eclipse.jst.server.core 4 0 2008-07-11 16:24:46.251
!MESSAGE Error calling delegate RuntimeClasspathProviderWrapper[org.eclipse.jst.server.generic.runtimeTarget]: null

So this must have been a bug in resolving the server classpath. I couldn’t find an equivalent problem description, and after playing around with the project settings, adding and removing the library manually, which didn’t help any further, I tried updating the Java Standard Tools. There was indeed a patch available. My previous version of JST was org.eclipse.jst_2.0.2.v200802150100-7B-7_8dDTOvmuz0di_U5vgUfz0em and I installed the patch org.eclipse.jst.web_core.feature.patch_2.0.2.v200803241913-208i8s733I395D6BA7. My Eclipse SDK version used is 3.3.2, Build id M20080221-1800.

After the installation of the patch and a restart of Eclipse, the JBoss v4.2 entry showed up again and the error message didn’t occur any longer in the log file. As I said, I don’t really know what had happened, but the patch might have resolved the issue for me, so maybe this helps someone out there, who runs into the same problem.

In many cases, Ant is the tool of choice for automating the build process. As far as I know, Netbeans already uses Ant as build tool by default. Eclipse has its own way of describing the project configuration (source/binary folders, required libraries etc.) with files like “.project” and “.classpath”. The naive approach for building an Eclipse project with Ant would be to duplicate all the information and write a separate Ant build file that does all the work and is independent of an Eclipse instance. There are several disadvantages that come along with this approach:

1. Inconsistencies may occur whenever a new library is added or the structure of the project changes in a significant way (e.g. a new source folder is introduced) => the build file has to be updated manually when the build fails.
2. There is no real guarantee that both the Eclipse and the Ant build produce the same output => Problems may not be visible until runtime tests are performed.

So what could be a more elegant solution? Of course, to use the information for the build that is contained in the Eclipse project artifacts already. The only tool I found up to now that does right this is ant4eclipse. Basically, it defines some Ant tasks that enable the following actions (from ant4eclipse’s website):

• Setup classpathes as defined in Eclipse’s .classpath-file
• checkout complete workspaces as it’s possible with the Team Project Set feature of eclipse
• run your Java applications as you have defined them in an Eclipse Launch Configuration

This avoids the redundancy and leverages the information that is already present as soon as the project compiles in Eclipse. To be honest, I haven’t evaluated ant4eclipse yet, but I probably will as soon as the next Continuous Integration project will start. Seriously, who would like to write dozens of Ant files to do the work that Eclipse already does?

Another interesting project that seems to focus solely on Eclipse plugins, features and RCP apps is Pluginbuilder. The tutorial movie looks really impressive. The homepage says that Pluginbuilder consists of two parts:

An Eclipse plug-in allows to configure the build in the project’s workspace and run the build locally

Then the configuration can be uploaded to the server platform where the build can be scheduled

That’s a nice alternative to the manual configuration of the Eclipse headless build and integration with e.g. CruiseControl. Haven’t evaluated that one neither, but this is definitely a very interesting and promising tool for Eclipse plugin and RCP development which I can imagine may be indispensable once you are used to it.

Which other tools for Eclipse build automation do you know?