A new release of XtendTools is available!

Release 1.0.1 contains some bug fixes and additions suggested in the comments of my blog post about the initial release of XtendTools (see change log for details) and also a complete Javadoc-like API documentation of XtendLib which has been generated using XtendDoc.

As usual, comments, suggestions and contributions are welcome!

During some of my last Xtext and/or Xpand based MDSD projects I wrote a lot of extensions and model transformations with Xtend. Unfortunately is it very hard to efficiently reuse extensions, if there was no API documentation at all or the documentation was scattered across a lot of files.

I really wished to have something like Javadoc for Xtend!

Well, to cut a long story short, here it is:

XtendDoc is a tool for generating HTML API documentation for the Xtend language. XtendDoc is obviously inspired by Javadoc and uses the same markup language and the generated documentation also looks similar to documentation generated by Javadoc.

You can download a preview version of XtendDoc right here:

• xtenddoc-preview-zip

XtendDoc uses Xtext 1.0 to parse the Xtend files and extract the comments. A good starting point for the Xtend grammar was the expression grammar by Moritz Eyshold and Knut Wannheden. The HTML documentation is generated using Xpand templates.

If you would like to have a look at the source code, or if you would like to participate, feel free to contact me!

Some days ago Sebastian showed How to Deploy Xtext to a Headless Plain-Java Envorinment. It’s nearly as easy to run the Xtext generator with Apache Ant.
[...]

Today, the first release of XtendTools has been published!

The Xtend Tools are a library of reusable extensions for Xtend/Xpand called Xtend Lib and a set of utility classes for testing Xpand templates and Xtend extensions using JUnit.

Xtend Tools is a utility project hosted at the Fornax Platform, a development platform for tools related to the Model-Driven-Software-Development – MDSD.

Xtend Tools is open source and released under the Terms of the Apache License 2.0.

Yesterday I started the open source project Groovy EMF Builder. The project is hosted at SourceForge and licensed under the Apache License 2.0.
[...]

Recently, I had to write a unit test for a class that used the MWE WorkflowFacade (which is part of the Eclipse MWE project). As usual I used EasyMock to mock the workflow facade.

Unfortunately, EasyMock failed to create a mock object for this class, due to a SecurityException. The Exception was raised because the package containing the class was signed and CGLIB was unabled to create a proxy class in the same package.
[...]

It’s quite simple to access private methods of classes using the Java reflection API. Here’s an example how to do it in a JUnit test case:

public class ArrayListTest {
    
    @Test
    public void testFastRemove() throws Exception {
        ArrayList cut = new ArrayList();
        cut.add("Test1");
        cut.add("Test2");
        
        Method m = ArrayList.class.getDeclaredMethod("fastRemove", Integer.TYPE);
        m.setAccessible(true);
        m.invoke(cut, 1);
        
        assert 1 == cut.size();
    }

}

As this breaks encapsulation, you should only use this, if ever, for white box tests.

I wrote some XSLT style sheets to transform FitNesse and fit4oaw XML reports to HTML or JUnit compatible test reports. The HTML reports contain the complete test output. However, the JUnit compatible test reports only contain the summary of each test. [...]

fit4oaw is a testing framework based on FitNesse for openArchitectureWare generators. To get automatic test reports the fit4oaw tests should be integrated into a continious build. In my case I am using Hudson to get my CI builds done; so I will demonstrate how to add fit4oaw to an Ant build that is run by Hudson. [...]

fit4oaw ist ein neues Open-Source-Projekt, das von Karsten Thoms ins Leben gerufen wurde. Es handelt sich dabei um ein Framework zum Test von openArchitectureWare-Artefakten wie Xpand-Templates, Xtend-Generator-Erweiterungen und Check-Constraints. fit4oaw schließt damit eine Lücke, denn bisher gab es keine Möglichkeit zur direkten Qualitätssicherung von MDSD-Generatoren. Lediglich die generierten Artefakte ließen sich mit den üblichen Tools (JUnit, TestNG etc.) testen. [...]