Here's the detailed program:

• 18:00 - 18:40 Welcome / Short films
• 18:45 - 19:15 Lars Vogel, Developing with e4
• 19:20 - 19:50 Sebastian Zarnekow, Xtext - A Language Development Framework, Live demo of new and noteworthy features in Xtext
• 19:50 - 20:20 Break + Surprise
• 20:20 - 20:35 Jürgen Becker, UI with style - a new SWT platform that is based on Qt
• 20:40 - 21:10 Ralf Ebert, Introduction to distributed version control with Git
• 21:15 - 21:45 Heiko Behrens, Build your own iPhone app within minutes - thanks to Eclipse
• 21:45 - open end Closing remarks / Frosty beverages

The DemoCamp will take place in the MAGAZIN Cinema in Hamburg (directions) and yes, we will show some short films at the beginning of the camp for your entertainment.

Martin Lippert and I are happy to be able to present a great lineup of speakers and demos, so do yourself a favor and join us this Friday from 18:00 (6pm).

As always, the event if free of charge thanks to the generous support of it-agile, itemis and the Eclipse Foundation.

Looking forward to seeing you on Friday!

Right after my talk, Heiko showed how Xtext and Xpand can be used to generate native iPhone applications - something that he and I are currently working on as a part of our day-to-day job at itemis. Heiko's slides also are available on Slideshare.

Something which - originally - wasn't related to code generation or iPhones at all was the e4 Mars Rover Challenge. In this challenge, the goal was to control a Mars rover (built with LEGO Mindstorms) in a Mars-like environment by using an Eclipse e4 based client and a set of server components hosted on Amazon EC2. In order to win, you either needed to score the highest score or improve the Eclipse e4 client. It was left to the developer's fantasy how to improve the client. In order to score the most points, you needed to drive the rover to certain places in the Mars arena and present one of two "tools" highlighted on the rover - see the rules of the challenge.

On the first day, I played some rounds with the basic e4 client (you needed to install it on your local machine) and scored quite OK. In the evening, after I dropped off my laptop in my room, it occurred to me that without my computer, I wouldn't be able to take the challenge that evening. "Wouldn't it be awesome to use my iPhone to control the Mars Rover", I thought? Compared to a laptop, an iPhone is a very small device so you can take it with you where ever you go. Also, as the Mars Rover Challenge was setup to be a completely distributed system, with the command server being hosted "in the cloud", delivering an image of the Mars arena to the clients, I should be able to connect to the rover from anywhere on the world (as long as I have access to the internet).

When I mentioned my thinking to Heiko, he was equally thrilled as I was and we immediately set out to take the new challenge of writing an iPhone client for the Mars Rover.

We discussed quite a few interaction patterns we wanted to try out:

1. Using buttons (much like the cursor pad on a keyboard) to "joystick" the rover
2. Using a touch interface to control the rover: use pinching to rotate the rover and pointing to make it move in a certain direction
3. Using the accelerometer to be able to control the Rover by tilting the iPhone

Heiko took on the job of evaluating the human interaction interface, whereas I was busy implementing the interface between the iPhone app and the command server backend. The command server of the Mars Rover is implemented as a RESTful webservice, so I could use plain HTTP calls to send commands to the server and to retrieve telemetry and imagery data. At first, I used blocking calls and later replaced them with asynchronous calls - sometingh which I'll liekly blog about the next days, so stay tuned. In order to test my code, I implemented a very simple button-based UI. With this UI, I was able to score 2702 points - not too bad!

After just two nights of development time (we wanted to attend the sessions and also had to man the itemis booth), we finally had a slick iPhone app that was able to control the Mars Rover by using the accelerometer. In the nght just before we had to hand in our submission, we shot a video of us driving the Rover. You can watch this video on the iPhone Mars Rover website.

Here is a little diagram outlining the controls of the application:

We knew right from the start that we wouldn't be able to match the competition criteria (the contest rules clearly state that the client has to be Eclipse e4-based in order to qualify). However, we still were eager to work on this project, as it fit very well with our current obsession with all things iPhones.

While it certainly is a fun idea to use an iPhone app to control a LEGO Mindstorms robot, we would not recommend using this approach for controlling real robots - especially if they're some 55 million km away on Mars! Signal latency from Mars to Earth is said to be around 15 to 20 minutes, which suggests to use a move-oriented approach to drive the rover.

Nevertheless it has been an exciting and fun project for Heiko and me. By the way, we're not only developing iPhone apps for fun, but also for profit: we're spearheading the brand-new mobile development division of itemis, so I'm pretty sure we will blog about mobile technology soon.

The program was packed with interesting talks and we were lucky to be able to present some very well known speakers:

1. Tom Schindl: E4 - A short overview
2. Jan Köhnlein: Combining graphics and text in model editors
3. Jochen Krause: RAP
4. Nils Hartmann, Gerd Wütherich: Fifty ways to build your bundle...
5. ekke (Ekkehard Gentz):redView - dynamic views for business applications

If you were not lucky enough to attend the DemoCamp, here is a short summary of the sessions:

e4 - modeling meets runtime (Jochen Krause on behalf of Tom Schindl)

Tom Schindl couldn't attend the DemoCamp due to heavy snow in Innsbruck (the airport was short of planes to fly out, actually). After a short vcon with Tom, Jochen Krause held the e4 demo on Tom's behalf.

e4 has three principal aims:

1. simplifying the Eclipse programming model
2. enabling the platform for use on emerging web-based runtime technologies
3. and broadening participation in development of the platform

One of the measures to make programming Eclipse easier is to define a list of core services and make sure they have a really decent API. This list of services is called "The 20 Things" (see the Eclipse wiki for more information).

You might have heard that EMF is playing an important role in e4 and I think it is one of the most amazing things about e4 that the entire workbench is modeled, of course using EMF. Actually, you can change the workbench at runtime by just modifying the underlying model at runtime. I think it is very exciting to see modeling and runtime technologies converge in this project.

e4 also makes massive use of dependency injection, which allows for a flat object model (Instead of providing a subclass for every special feature, you can just inject other classes providing that particular feature). We had a discussion about dependency injection. Jochen showed that several methods in e4 use String-based dependency injection, which of course leads to several problems. Sven pointed out that this is not a DI problem per se and suggested to use interfaces to alleviate the situation.

Heiko raised the question of whether we should have a dedicated session on dependency injection at one of the next democamps:

Jochen continued his session, explaining how the e4 UI is being rendered by a presentation engine which can be configured using various renderers, each one providing an individual look and feel.

e4 is the future of Eclipse, and Jochen concluded his talk by pointing out that in order to ensure e4 has a sustainable future, companies and individuals should participate in the development of e4. This can be done by:

• Playing around with e4 and providing feedback
• Participating in the development process (see the e4 project homepage for more info)
• Paying existing committers (see Tom's blog posting to learn how to buy one and get one free)

More info on e4 can be found on the Eclipse wiki.

After the talk, we had a short break to set up the next presenter, enjoy some refreshments and, of course, socialize:

Combining graphics and text in model editors (Jan Köhnlein)

After the break, Jan Köhnlein took stage and told the audience that graphics and text and no different, but really are just two views on the same thing:

Jan pointed out that both text and graphics have their relative virtues:

Text...

• provides a detailed view on things
• can have a very formal syntax
• can be typed using standard text editors
• can be managed using standard versioning mechanisms (merge / diff)
• can be typed fast

Graphical representations on the other hand...

• provides high-level views and a good overview
• suggests non-formalism
• requires custom editors for your graphical notation (i.e., you need to write them)
• has no good support for merging / diffing
• requires the user to use a mouse a lot, and thus is slower than a text editor

Apparently, both have advantages, so why not use both?

In the following 5 minutes, Jan gave an ultra-quick introduction in how Xtext (as a representative of a textual modeling toolkit) and GMF (as a representative for a graphical modeling toolkit) work. The bottom line is both use Ecore metamodels, so we should be able to combine both.

It turns out, however, that Xtext and GMF metamodels are slightly different and you need to take some precautious steps in order to make them interoperable.

After this excursion into the theory behind the convergence of graphical and textual editors, Jan showed two editors, one graphical and one textual that synced live. Changing the model in one editor and saving it effected an immediate update in the other editor - really neat.

Jan pointed out that this is all very fine, but sometimes you really want to have a tight integration. As a proof of concept, he showed a GMF-based editor with an embedded Xtext editor: as soon as he pressed F2 to edit a field in the graphical editor, an inline Xtext editor would pop up, featuring syntax highlighting, code completion and error markers - really awesome!

More information on Xtext and GMF can be found on their respective homepages. Jan works for itemis and provides consulting and training for these technologies.

All these exciting things must have made people gasp for air, because the oxygen level in the room was very low at the end of the session, so we had another break. As always with gathering like this, hallway talks very equally important as the sessions, and people made good use of the break:

RAP (Jochen Krause)

Jochen's presented his talk on RAP without a single slide - "in the tradition of the Karlsruhe DemoCamps", as he pointed out.

No technical session without some history and some theory, so Jochen first explained that RAP implements the Half Object Pattern and demoed the very first version of RAP. While running an Eclipse UI in the browser is all very exciting, feedback from initial users wasn't too positive: "please spare us this look'n'feel in the browser!"

So the good people at innoopract (now EclipseSource) spent some time to implement custom styling for RAP UIs, which Jochen showed in his second demo, which he called "The Enterprise Look'n'Feel" due to it's feasibility for enterprise applications.

The third demo featured "rounded corners" (see RAP New & Noteworthy). While this might seem like little gained, Jochen explained that implementing rounded corners was both important on an acceptance level and challenging on the implementation level. Would you have thought that rounded corners are implemented using CSS on FireFox and VML on Internet Explorer?

Of course, RAP is implemented as an Open Source project at Eclipse, welcoming any contribution from users worldwide. Jochen demonstrated how great the Open Source model works by showing off a ribbon-style command bar for RAP which is available on Google Code (see the rapit project home page)

In the next demo, Jochen showed how he integrated EMF and RAP. His goal was to RAPify the EMF tree editor for EMF models. It turned out that basically it is very simple to convert the EMF editor (or any other Eclipse plug-in for that matter) into a RAP application - only very little adjustments were needed. However, as web applications are multi-user applications by definition, additional care has to be taken when converting editors. As Eclipse is a single-user application, editors are not prepared to be executed in a multi-user environment. Jochen explained how he tried to use CDO to store the edited models on a remote server, but failed due to the complexities of CDO. He succeeded by using CouchDB, a database written in Erlang and with an HTTP interface (look ma - no JDBC driver needed!).

Jochen concluded his session with a few notes on features they've just completed (Drag'n'Drop) or which are not available (yet) like GC.paint.

After that, he took some of the audience's questions, e.g. "How many users can a RAP server take?". Of course, it depends, but you can roughly count 1MB per user and workbench.

Jochen thought it would be OK to continue without a break, but Martin decided we should rather have a short break to let in some air.

More information on RAP can be found on the Eclipse wiki and on the project homepage. Jochen's company EclipseSource provides professional services, training and resources around RAP, so have a look at their website.

50 ways to build your bundle (Gerd Wütherich & Nils Hartmann)

After the "short" break, Gerd Wütherich and Nils Hartmann presented their view on build management: "Fifty Ways to Buid Your Bundle":

Facing the fact that nobody seems to be too excited about build management these days, they decided to arrest people's attention by adapting the well-known story "A Christmas Carol" by Charles Dickens. A brilliant idea, which really made people laugh at various points throughout the presentation.

The presentation was subdivided in three parts:

The Ghost of Build Past
Gerd and Nils explained how in the past, people have been building bundes using PDE build, using a Manifest-First-approach. Building bundles with PDE build is rather cumbersome: you have to setup map files in order to help PDE build to derive ANT build files which will then be executed by the AntRunner inside Eclipse. While this ensures the build process sees exactly what Eclipse sees when you develop your bundles in the workspace, this basically makes debugging your build process very complicated.

The Ghost of Build Today
Today, we've got bundles everywhere and OSGi is being used not only for Eclipse plug-ins, but also for conventional applications. As good programers obeying the DRY principle, we want to have a redundancy-free description of our build artifacts, i.e. derive build dependencies by looking at MANIFEST.MF. In the enterprise, things can get really nasty, as we often need to integrate various very different build systems: you might have to build an EJB client JAR (maybe using Maven) which then need to be integrated in an Eclipse RCP client application, which again needs to be built using PDE build.

Nils and Gerd showed a slide which listed all major build tools for bundles, among them:

• Springsource Tool Suite
• PDE
• Athena
• PluginBuilder
• Buckminster
• Tycho
• Maven
• b3
• Ant4Eclipse
• PDE build
• bnd
• Ivy
• Buildr
• IDEA
• Sigil
• buildr4osgi
• OsgiPlugin
• ANT
• Bundlr

After which they showed three exemplary setups how to actually build bundles:

1. ANT4Eclipse
2. Maven Tycho
3. Buckminster

Please refer to their slide deck, slides 14 - 16 for detailed diagrams on these three setups:

Ghost of Build Future
As things get more complicated, build management will also most likely become more complicated. Gerd and Nils pointed out that build management might be an unthankful job, but it must not be assigned to "people that aren't good at programming". Instead, they advocated making build management a first class citizen in computer sciences education.

More information on the tools and techniques presented are available at their respective home pages. In addition, you can contact Nils and Gerd and bug them with your questions. They're consultants, so they can be hired.

redView - dynamic views for business applications

The final session was held by Ekkehard Gentz, better known as ekke. He showed a smart combination of Eclipse technologies: Riena, EMF, openArchitectureWare (Xpand, Xtend, MWE) and Xtext. Of course, being an Open Source advocate, Ekke and his team mate Florian provide this stack as an Open Source project on Google Code.

redView is a declarative framework based on the Eclipse Modeling Framework (EMF), for creating RCP Views enriched with Riena Ridgets. It uses EMF to describe the application with a model. An Xpand-based code generator will then transform the model into code for the application. Ekke states that their goal is not to limit developers' creativity, but instead relieve them from the burden of having to write all the boilerplate code.

redView supports the most important UI elements, including some Nebula widgets. One thing I fond very impressive was their UI editor. Ekke gave a demo in which he hosted the UI model on a CDO (which seems to be Eclipse's wunderkind) server on a virtual machine. He started a second virtual machine, running an instance of the application. Upon changing the UI model in the UI designer on one machine, the UI was updated immediately on the second machine. Ekke pointed out that this usage pattern is especially useful in prototyping scenarios: the developer changes the model on his PC in his office and the customer can immediately see the changes on his machine, hundreds of kilometers away.

More information on redView can be obtained from their project homepage. Ekkehard is a freelance consultant, so you can hire him if you've got any questions regarding the technologies presented.

Gimmicks

After the demos, we raffled off 20 Eclipse Keybinding Mugs (see Kim Moir's blog post for a 360° shot of the mug) - congratulations to all winners! it-agile also provided a fine selection of agile swag: retrospective mugs, team calendars, post-its and what have you:

Despite the fact Ralph Müller couldn't attend the event, we eventually headed to the EAST bar for some frosty beverages.

All in all, it has been a very enjoyable event and from what I gathered, most attendees seem to have enjoyed the DemoCamp as well.

Thanks everyone for attending! Also, thank you to all speakers. Last but not least a big thank you to Natalia for taking pictures of the event!

Hope to see you again at the next DemoCamp in Summer 2010!

• Eclipse in the Enterprise: Lessons from Google
• Distributed OSGi
• Deploying Successful Enterprise Tools
• Build and Provision

all dealt with how Eclipse can be used in the Enterprise or which challenges you will face if you start using Eclipse in large-scale scenarios.

The talks

• Developing DSLs with Eclipse
• Eclipse in NASA Mission Control
• Build and Provision

either directly had modeling as their topic or used modeling technology to solve their problems. I especially liked the NASA talk which featured a number of computer animated videos of recent or future missions. The NASA mission control software is heavily based on Eclipse and technology form the Eclipse Modeling Project. Finally, there were some talk on runtime technology:

• OSGi for Eclipse Developers
• Developing for Android with Eclipse
• Google Plugin for Eclipse: Not Just for Newbies Any More

Attending great talks of course is one of the major benefits of going to a conference like this. To me, meeting other people and connecting has become even more important than attending great talks. Of course, this is nothing new to event organizers and so there were many chances to grab a drink and chat with the other attendees. With more than 170 people attending, it was hard to have a chat with everyone, but nevertheless I managed to talk to a number of people, many of which already are Xtext users or are now planing to have a detailed look at it. Even Google is using Xtext, but ssshh! Overall, I really enjoyed my two days at Google and look forward to more events like this. Speaking of which, Eclipse Summit Europe is approaching fast, so make sure you register on time. Also, if you're interested in Modeling and DSLs, we're organizing a Modeling / DSL Day in North America this coming fall - see my previous post for more info. And finally, here are the slides and the video of my talk:

http://spreadsheets.google.com/viewform?hl=en&formkey=dF ZQcGh3RDhrUUdyNTAtMXlVU2pKQ1E6MA..

Our goal is to organize an event especially for people new to modeling or who are curious what this modeling fuss is all about and how it can help them. So, this will not be an experts meeting, but you can meet experts talking about their topics. We also are interested in case studies, so ideally you will get first-hand experience from people who use modeling in real life to meet real challenges.

We welcome any feedback, so please fill out our little poll.

Neil was kind enough to invite someone from the "modeling/oAW folk", so Heiko Behrens will be giving an Xtext demo.

If you haven't had the chance to attend Code Generation 2009 or if you're curious what all this DSL talk is all about, I urge you to sign up for the DemoCamp now - it is free of charge.

I was fortunate enough to hear Heiko speak at the DemoCamp in Hamburg. Not only is Heiko a very good speaker (with a very convincing, deep voice), but also did he manage to come up with some very good examples of what a DSL is and why you should consider using them in your projects.

By the way, if you want to play around with Xtext before the DemoCamp, you can get a fresh copy from our download site at http://xtext.itemis.com.

Although we had quite a bunch of attendees (I counted 40), only one brought his Towel.

Thanks to our speakers, Martin and I were able to put together a really exciting program:

1. Moritz Eysholdt, Patching Models and Evolving Meta Models
2. Heiko Behrens, TMF Xtext
3. Simon Zambrovski, Common Navigator Framework
4. Marco Mosconi, Modular EMF/GMF customization with ObjectTeams/Java
5. Markus Alexander Kuppe, Distributed OSGi (RFC 119) - The ECF way

Moritz presented the result of his master's thesis on the topic of metamodel evolution and explained how models can evolve together with their metamodels. This might also be of interest for data modeling.

Heiko delivered a great presentation on the upcoming version of Xtext. He used a well-known example that everybody could relate to (no, not entities and services!) so it was really easy to understand how domain specific languages work and how Xtext can help to implement a domain specific tool chain.

Simon presented on the Common Navigator Framework - a powerful framework which helps you to assemble tree views in a mostly declarative manner. Simon was bold enough to do a live coding session, but the demo gods didn't smile on him, so he showed us the prepared solution, which was still very convincing. Simon prepared an article about the CNF on his blog, so if you're interested, drop by - it's worth a read.

After the break, Marco Mosconi showed how ObjectTeams/Java can be used to non-invasively customize generated code. As a real-world example he used the UML diagrams from the Eclipse UML2Tools project. The UML2Tools project uses GMF to generate the diagram code based on the UML2 metamodel (implemented as an ECore model). A rather large number of generated artifacts have to be customized to make sure the diagrams behave correctly. Marco showed how this is especially required for associations (I find it kind of funny how everybody uses associations to explain how complicated the UML metamodel is). The UML2Tools class diagram has been customized in at least 200 different locations, so you get a big maintenance problem (generated and non-generated code are mingled). With ObjectTeams, it is possible to extract all customization code into so called teams which then are able to enhance the generated code in an aspect oriented way. In a way, ObjectTeams is like AOP on steroids.

The official part of the DemoCamp was concluded by a talk held by Markus Kuppe on Distributed OSGi. Markus briefly explained the architecture behind Distributed OSGi and gave a demo of an Eclipse RCP application that communicated with an iPhone (which ran an Equinox server). Markus used the Eclipse Communication Framework (ECF) to achieve this - ECF contains a provider for Distributed OSGi.

Eclipse DemoCamps are social events and aim at creating room for discussion and interaction. So, after the official part of the DemoCamp, we headed down to the EAST Bar to have some nice chats over some frosty beverages (I definitely recommend "Cool Mango").

Feedback has been very positive so far and I surely hope everybody enjoyed the DemoCamp as much as I did. Thanks to the Eclipse Foundation, it-agile and itemis for making this event possible by sponsoring the location and the drinks!

If you feel you missed out, drop me or Martin a mail so we can invite you the next time around.

On Monday, Bernd, Kenn and I hosted the official Modeling BOF:

The topics discussed were focussing on consumability and long-term sustainability of EMF:

Documentation and Marketing

We all agreed that the entire modeling project lacks a decent documentation. While of course all of the projects and subprojects do have their own documentation, there is so such thing as an overview documentation. Modelers as we are, we quickly realized we're lacking a documentation superstructure. The idea is to provide a guide for users (newbies and seasoned experts alike) to navigate the Eclipse Modeling world. The modeling project offers a great variety of technologies, so it is not always easy to find out which set of technologies / frameworks you might want to use - especially if you are new to EMF.

We also agreed that we need more success stories (in the form of blog entries, articles and shiny flyers for the modeling landing page). A quick poll revealed that more than 90% of all people attending have been working on projects in which modeling was successfully applied, so there should be enough material to create success stories!

Kenn mentioned the Eclipse Foundation wants to start a documentation project (much like Babel) to improve overall documentation, we might eventually join this project. In the meantime, we decided to form a working group comprised of members of the Eclipse Modeling Project that starts to create this overview documentation. The initial members of this working group will be Kenn, Bernd, Peter, Tamer, Pierre, Marcello, Thibault and Anthony (guys, please send me your email addresses). The working group will start its work on the EMF dev mailing list. You are welcome to join us there.

Consuming Modeling Technology

I think there is no other technology that causes more emotions in an Eclipse committers life than P2. So we also had our little discussion about how to best provision Modeling technology. No big news here - we just re-iterated the pros and cons of using ZIPs vs. P2 and also had a short discussion about the Friends of Eclipse Download Wizard (which, rumor has it, will allow you to assemble a custom distro by just selecting the pieces you need). Several people mentioned that Amalgamation is intended to be a place for modeling distros.

EMF 3.0

We also discussed whether we should have a new major release of EMF that allows us to break API. Though not everybody agreed that we need a new major version (because the current version works smoothly for most people) we decided to set up an additional BOF to discuss this topic in more detail. I will write about the EMF 3 BOF later (yes, I am teasing)

Miscellanea

Someone asked if we need something like a model bus, the answer was no - we've got the modeling workflow engine (MWE).

We also briefly discussed the recent change of leadership on the MDT OCL component (Christian Damus revoked his committer and component lead status recently). Everybody agreed that to lead a component, a long-term committment is needed (which has been met by Christian in the most excellent way). We also agreed that we need to make avoid situations in which a whole bunch of projects / components suddenly are without a leader. This will be a task for the PMC.

After the official part of the BOF, there still was time to chat and shake hands with people you never met in person before. I had the pleasure to shake hands with Anthony Hunter, who works for IBM. From our discussions on mailing lists and bugs, you could guess that we have a totally different view on the marketing of software, but it turns out we're actually not that far apart

BOFs are a great way to interact with like-minded people at conferences. So, next time you go to a conference, make sure you participate in a BOF to make yourself be heard and take part in the discussion.

So, I gave a short demo of Xtext and Xpand to show Chris how easy it is to create (model-aware) code generation templates. Xpand comes with a nice editor which makes template editing a joy - it features code highlighting, hyperlink navigation, model-awareness and other editor goodness.

Instead of letting only Chris know how that works, here's a short guide on how to write your own Xpand template and use it in a wizard. To make the example more realistic, I chose to implement a wizard that creates an Ant build.xml file for a simple project (something which is missing in Eclipse, AFAIK). So, here we go.

Prerequisites:

• Eclipse 3.5M3 (3.4 might also do)
• EMF 2.5.0M3
• EMF Compare 0.8.1
• MWE 0.7.0M3
• Xpand 0.7.0M3

How to do it

1. Download and install the prerequisites.
2. Create a new plug-in project named "de.peterfriese.antwizard"
3. Add a New File Wizard to the project. I used the Custom plug-in Wizard to get me started.
4. Brush up the wizard page and add some fields for project name, source folder and binary folder.
5. We want to transfer the values entered in this wizard into our template, so we need to create an Ecore model that describes our data model.
   

6. Add org.eclipse.emf and org.eclipse.emf.edit to the dependencies of you plug-in.
7. Create a genmodel and let EMF generate the model code for you.
8. Add code to your wizard that transfers the values from the input fields to your model. One might consider using databinding for doing this, I used a straight forward read'n'write approach for the time being:

   public boolean performFinish() {
       final String containerName = page.getContainerName();
       final String srcDirName = page.getSrcDirName();
       final String binDirName = page.getBinDirName();
       // ...
   }
   private BuildSpecification createModel(IProject project, String srcDirName,
       String binDirName) {
       BuildSpecification buildSpecification = BuildspecificationFactory.eINSTANCE.createBuildSpecification();
       Project projectSpecification = BuildspecificationFactory.eINSTANCE.createProject();
       projectSpecification.setName(project.getName());
       projectSpecification.setBinaryFolder(binDirName);
       projectSpecification.setSourceFolder(srcDirName);
       buildSpecification.setProject(projectSpecification);
       return buildSpecification;
   }

9. Create an Xpand template de.peterfriese.antwizard/src/template/BuildTemplate.xpt:
   
   

   
   In case you wonder how to get those funky characters: make sure us create this file using the Xpand editor - it has code assist (CTRL + space) for those characters.

10. Create an Xtend file de.peterfriese.antwizard/src/template/GeneratorExtensions.ext:
    
    

11. Add org.eclipse.xpand, org.eclipse.xtend and org.eclipse.xtend.typesystem.emf to the depencies of your plug-in.
12. Finally, we need to provide some code to invoke the generator:

    private void generate(BuildSpecification buildSpec, IProgressMonitor monitor) throws CoreException {
    
        // get project root folder as absolute file system path
        IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
        IResource resource = root.findMember(new Path(buildSpec.getProject().getName()));
        String containerName = resource.getLocation().toPortableString();
    
        // configure outlets
        OutputImpl output = new OutputImpl();
        Outlet outlet = new Outlet(containerName);
        outlet.setOverwrite(true);
        output.addOutlet(outlet);
    
        // create execution context
        Map globalVarsMap = new HashMap();
        XpandExecutionContextImpl execCtx = new XpandExecutionContextImpl(output, null, globalVarsMap, null, null);
        EmfRegistryMetaModel metamodel = new EmfRegistryMetaModel() {
            @Override
            protected EPackage[] allPackages() {
                return new EPackage[] { BuildspecificationPackage.eINSTANCE, EcorePackage.eINSTANCE };
            }
        };
        execCtx.registerMetaModel(metamodel);
    
        // generate
        XpandFacade facade = XpandFacade.create(execCtx);
        String templatePath = "template::BuildTemplate::main";
        facade.evaluate(templatePath, buildSpec);
    
        // refresh the project to get external updates:
        resource.refreshLocal(IResource.DEPTH_INFINITE, monitor);
    }

That's it!

Taking it for a spin

1. Launch a runtime workbench by selecting de.peterfriese.antwizard/META-INF/MANIFEST.MF and invoking Run As -> Eclipse Application
2. Create a new Java project in the runtime workspace.
3. Invoke your wizard by selecting File -> New -> Other... -> Ant -> Ant build file from existing project
4. Enter the required information (project name, source folder, binariy folder)
5. After clicking on finish, you should get a fresh Ant file for your project:
   
   

6. Enjoy!

You can download the project here. Feedback and comments are welcome!

I guess you all agree with me that refactoring support is crucial for any programing language, as you need to restructure your code rom time to time.

Although Eclipse LTK offers a decent API and UI to realize refactoring tools, all the heavy lifting (parsing the text in question, analyzing the AST, creating rewrite rules) is left to you.

Jeff's research tool Ludwig can help to derive refactoring support from a BNF-style grammar very easily. Ludwig essentially derives a lexer/parser from the grammar and provides an interface to the AST which gets constructed by the parser. Which gives you the chance to walk / visit the AST and (partially) rewrite the AST.

I really enjoyed Jeff's presentation style. He used a set of slides and pre-recorded screenvideos to drive his talk. I think this is great idea, as it basically eliminates any problems you might run into if you do a live demo. Plus, it gives the presenter the chance to face the audience while demoing, instead of mumbling into the screen