Eclipse DemoCamp Dortmund – June 8th at FZW

During June and July 2010 there will be again Eclipse DemoCamps all over the world to celebrate the upcoming Eclipse Helios release end of June and e4 release and of July. DemoCamps are a great opportunity to see the latest and coolest new features live from the top experts in their field. Often the speakers are themselves committers on the projects and technologies they present. Also most attendees are Eclipse enthusiasts or use Eclipse technology for mission critical projects in their companies.

And to make it even better – these events are for free! All you have to do is take some time, come and enjoy!

I started now to organize the Eclipse DemoCamp in Dortmund. The Eclipse Foundation is sponsoring these events, but only 5 per country. In Germany there is such a huge interest in these events that these 5 sponsored DemoCamps were already registered when I entered the Dortmund DemoCamp – and this was just hours after announcement! Fortunately this DemoCamp will take place anyway, since itemis , who are Strategic Member of the Eclipse Foundation,  is willing to sponsor it.

This week we contracted the room, so finally location and date of this event is known and further planning can continue. The Eclipse DemoCamp in Dortmund will take place on June 8th 18:00-21:30 at the new FZW. The FZW is a well-known location for events and concerts and recently re-opened near to the “Dortmunder U” of the former Dortmunder Union Brewery.

Join the DemoCamp!

The Eclipse DemoCamp Dortmund is an open event. The only requirement for attending the event is registering on the Event Wiki page. To register you will need an account for the Eclipse Bugzilla System or contact me if I should add you to the attendees list.

Currently I am also searching for speakers. If you like to demonstrate what amazing stuff you are doing with Eclipse then go ahead. Just enter your name and the title of your presentation on the Wiki page. It could be anything which is related to Eclipse. Best of course would be demonstrations of features that come up with Helios or of some incubation projects. Each presentation should be no longer than 20 minutes. I’m especially interested in presentations about e4, XtextRAP, SMILA, b3, Cloud Development Toolkit, Sphinx, redview, Teneo, Equinox/OSGi, (E)Git, Graphiti, to name just of few of exciting Eclipse or technologies or Eclipse based products.

DemoCamps are a rather informal event. Besides the presentations there will be enough time to talk with the people there, do networking and drink a beer together. DemoCamps are fun and of high information value.

Don’t miss it and join it now!

Spread the word!

Eclipse DemoCamps are interesting for all users and devlopers of Eclipse. Talk with your colleagues and friends and make them aware about the Eclipse DemoCamp series around the world. There are lot of events planned and sure some more that are scheduled later. Of course, if you are coming from the Ruhrgebiet or somewhere around Dortmund you are welcome to join there. Hope to meet you there!

Sponsors welcome!

The event is at the moment sponsored by itemis, but it is not restricted to. Also your company can be a sponsor for this event. Your company will be mentioned on the Event wiki, mentioned in the opening talk and you are allowed to distribute marketing material. A better opportunity to present yourself as Eclipse experts for a reasonable price your company won’t find! Contact me if this is interesting for your company.

Advertisements

Mavenizing the project structure of Xtext projects

The structure of typical Xtext projects does not match the standard layout of Maven projects. Xtext projects more adhere to standard Eclipse project layout, which means

  • manual implemented Java sources are in folder /src
  • the plugin Manifest is /META-INF/MANIFEST.MF
  • generated sources go to /src-gen

In my customer’s project Xtext sources are built with Maven, and also the sources produced by Xtext are produced within the Maven build, using the Fornax Workflow Maven plugin. Until now we have adjusted the Maven build to match the standard Xtext project structure, which requires some configuration in the build section of the POM like follows:

   <build>
        <sourceDirectory>src</sourceDirectory>
        <resources>
            <resource>
                <directory>src</directory>
            </resource>
            <resource>
                <directory>src-gen</directory>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <groupId>org.fornax.toolsupport</groupId>
                <artifactId>fornax-oaw-m2-plugin</artifactId>
                <version>3.0.3</version>
                <configuration>
                    <checkFilesets>
                        <checkFileset>
                            <directory>${basedir}</directory>
                            <includes>
                                <include>src/**</include>
                            </includes>
                            <excludes>
                                <exclude>**/.svn/**</exclude>
                            </excludes>
                        </checkFileset>
                    </checkFilesets>
                    <outletSrcDir>src-gen</outletSrcDir>
                    <outletSrcOnceDir>src</outletSrcOnceDir>
                    <outletResOnceDir>resources</outletResOnceDir>
                    <properties></properties>
                    <workflowDescriptor>xtext/example/GenerateMyDsl.mwe</workflowDescriptor>
                    <workflowEngine>mwe</workflowEngine>
                </configuration>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>run-workflow</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>add-source</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

Now requirements changed and the project structure should conform to the Maven structure, which means:

  • src/main/java: Contains hand-written Java code
  • src/main/resources: All non-Java hand-written code (including Workflow and Xtext grammar)
  • target/generated/java: Contains generated code

Another requirement  from the build team is that the actual output directory ‘target’ should be configurable. This means mainly that we have to use properties that Maven uses to refer to the source and target directories (project.build.sourceDirectory and project.build.directory), so that the build could override just these settings by passing a system property and all output gets produced to and compiled from an alternative directory structure.

Of course this is possible with small changes, but you have to know where.

Xtext Generator Worklow

In order to produce the output of the Xtext generator to different directories than default (src, src-gen => src/main/java, target/generated/java) the MWE workflow file has to be changed. For the generator component we have to override the properties srcPath and srcGenPath. Further, these output directories should be parametrized by the same properties that Maven uses, namely project.build.directory and project.build.directory. These properties need to be configured in the Generate<MyDSL>.properties with defaults.

Generate<MyDSL>.mwe

<workflow>
  ..
  <component class="org.eclipse.xtext.generator.Generator">
    <pathRtProject value="${runtimeProject}"/>
    <pathUiProject value="${runtimeProject}.ui"/>
    <projectNameRt value="${projectName}"/>
    <projectNameUi value="${projectName}.ui"/>
    <srcPath value="/${project.build.sourceDirectory}"/>
    <srcGenPath value="/${project.build.directory}/generated/java"/>
    ..
  </component>
  ..
</workflow>
<pre>

Generate<MyDSL>.properties

basedir=.
project.build.directory=target
project.build.sourceDirectory=src/main/java
grammarURI=classpath:/.../MyDSL.xtext
file.extensions=...
projectName=...

pom.xml: build section

The Java source directories also contain non-Java resources, like the workflow, grammar file etc. Normally this would go to the resources directory for Maven projects, but Xtext (0.7.2) cannot be configured to produce resource files to another directory than Java sources. On the other side those resources need to be found on the classpath during the build. This requires that we add the Java directories as resource directories in the build section of the POM. This settings already existed before, it just has been adopted.

Before:

    <build>
        <sourceDirectory>src</sourceDirectory>
        <resources>
            <resource>
                <directory>src</directory>
            </resource>
            <resource>
                <directory>src-gen</directory>
            </resource>
        </resources>
        ...
   </build>

After:

    <build>
        <resources>
            <resource>
                <directory>${project.build.sourceDirectory}</directory>
            </resource>
            <resource>
                <directory>${project.build.directory}/generated/java</directory>
            </resource>
        </resources>
         ...
     </build>

The <sourceDirectory> entry is not necessary anymore, since the main Java source directory is now src/main/java, which follows the Maven standard directory layout and gets automatically compiled.

maven-clean-plugin

Xtext produces output into two projects – the grammar project and the UI project. Now if the generated UI sources are produced below /target calling ‘mvn clean install’ would have an undesired side effect. Maven builds both modules after each other, so when the UI module is built with the goals ‘clean install’ the target directory is removed and the previous generated sources get lost.

The solution is that the maven-clean-plugin must be deactivated for the UI module and the grammar module must clean the target directory for the UI module.

pom.xml – Grammar project

<plugin>
    <artifactId>maven-clean-plugin</artifactId>
    <configuration>
        <filesets>
            <fileset>
                <directory>../my.dsl.ui</directory>
                <includes>
                    <include>${project.build.directory}</include>
                </includes>
            </fileset>
        </filesets>
    </configuration>
</plugin>

pom.xml – UI project

<plugin>
    <artifactId>maven-clean-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin>

Eclipse settings

The new project structure affects, of course, the project settings for Eclipse. The settings apply for the grammar and UI plugin.

build.properties

Change the source folders in the build.properties file:

source.. = src/main/java/,target/generated/java/
bin.includes = META-INF/,\
 .,\
 plugin.xml

Java build path

Open the project properties and change the  Java Build Path settings:

  • Source Folder src -> src/main/java
  • Source Folder src-gen -> target/generated/java
  • Default outputr folder: bin -> target/classes

Xpand builder deadlock situation

Today a colleague in my project came with an issue she experienced with several workspaces, which contain amongst others Xpand projects. After starting Eclipse during the initial build phase Eclipse hang and did nothing. In the workspace log we found indication for a deadlock situation, since there one of the last entries stated that thread Main was waiting for thread Main, and this happened during class loading of the XtendXpandBuilder. We debugged the situation and from the stacktraces of the running threads we could see that one thread tried to refresh a resource that was out of sync.

The problem was solved by starting Eclipse with the -refresh platform option. The out-of-sync resource was synchronized before the builder runs.