Skip to Content
Author's profile photo Marion Schlotte

Isn ‘t it Groovy – extending the Development Component build with Groovy?

Let’s say we heard that something called “Groovy” just won the JAX innovation award 2007 and we want to use it.

Note: SAP does not endorse Groovy or support usage. This is just an example for a popular technology and how to integrate it into the development component build.

What does that something do?

In simple terms Groovy is a script language that extends the Java language. Groovy scripts can be compiled to Java bytecode or executed at runtime using a GroovyShell.

How do we want to support that?

We want to allow developers to use Groovy instead of Java to write applications. That means that we need to integrate the groovy compiler into the build process. Since Groovy is very similar to Java we will define the Groovy compiler as an extension to the Java compiler.

    • Groovy scripts are compiled to standard Java classes. If we define Groovy as an extension for the Java compiler the Java Entity handlers will work without any additional modifications.

Since we only want to extend a specific compiler we will create a Build Infrastructure Extension DC. That way we can use Groovy with all existing DC types that already use the Java compiler.

What other options are there?

Define Groovy as a standalone generator. This generator could be used without invoking the Java compiler. If we do not have real Java sources this can save some build time, but we would need to reconfigure the Java entity handlers or create new entity handlers to handle Groovy generated classes. This is much more effort and a more complicated scenario than extending the Java compiler.

How to extend the build?

Enable NWDS for creating Build Infrastructure Extension DCs

Note: If the entry does not appear try to restart NWDS with the option -clean.h4. Create a Build Infrastructure Extension DC

Create a new Development Component of type “Build Infrastructure Extension”.


In that example we use as vendor and tc/bi/fct/groovy as name.

Naming convention: tc = technical component, bi = build infrastructure, fct = facet.

image After creation the package structure should look like this.

Note: You may have to turn off the filter for .*resources to see the .bpfext file.


Copy the groovy-all<version>.jar into the folder bp/lib/java.

Edit the .bpfext descriptor to define a Groovy extension for the Java compiler with a special postprocessor macro. It tells the Build Plugin Framework to execute a macro called GroovyCompilation with a predefined signature after each invocation of the Java Compiler.


Edit the macro file example.org_tc_bi_fct_groovy.vm to define the GroovyCompilation macro:create a DC using any type that uses Java compilation, e.g. a simple Java DC or a +J2EE/EJB Module DC +0.1.

add a build-time dependency on the def public part of the tc/bi/fct/groovy DC. The def public part was automatically created when creating the Build Infrastructure Extension DC.!|height=345|alt=image|width=385|src=|border=0!

Now you can add your groovy script files and put them under the src folder of your new DC.

Here is an example for a Groovy script file helloworld.groovy:


Build the DC and you will see within the build log file some entries for the Groovy compiler (groovyc).


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hi Marion,
      so cool. There is much too less such contributions in the area of NWDI !
      Author's profile photo Former Member
      Former Member
      Hi Marion,

      cool feature. Can we use it, to run JUnit tests?

      Kind regards