Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 129812 - Build support in Netbeans module projects
Build support in Netbeans module projects
Status: NEW
Product: groovy
Classification: Unclassified
Component: Code
All All
: P3 (vote)
: 6.x
Assigned To: martin_adamek
Depends on:
  Show dependency treegraph
Reported: 2008-03-11 17:22 UTC by ynb
Modified: 2010-01-12 18:25 UTC (History)
0 users

See Also:

an example of build.xml for a single Nb Module project (562 bytes, text/xml)
2008-03-14 22:43 UTC, ynb
"compile" task that uses groovyc instead of javac, it just overrides the standard one from common.xml (2.24 KB, text/xml)
2008-03-14 22:44 UTC, ynb
respect JVM set in; added do-test-build task which overrrides the standard one to support groovy unit tests (5.39 KB, text/xml)
2008-03-16 19:36 UTC, ynb

Note You need to log in before you can comment on or make changes to this bug.
Description ynb 2008-03-11 17:22:10 UTC
It would be nice to support groovy files in Netbeans module projects.
Currently, it just copies groovy files into the jar.
I'm using the following task to compile but haven't figured out how to connect to to "build" task (nb5 had various pre-
and post- tasks but nb6 does not),
also NB does not notice groovy code and if there is no java code, thinks that the package exposes no API:

<?xml version="1.0" encoding="UTF-8"?>

<project name="groovy-compile-impl" default="groovyc" basedir="..">
   <property file="nbproject/"/>

    <target name="groovyc" depends="init,module-auto-deps" description="groovyc">
        <mkdir dir="${build.classes.dir}"/>
        <path id="classpath"> 
            <pathelement path="../wrapper-groovy-all/release/modules/ext/groovy-all-1.5.4.jar"/>
            <pathelement path="${module.classpath}"/>
            <pathelement path="${cp.extra}"/>

        <taskdef name="groovyc" 
            <classpath refid="classpath"/> 
        <groovyc srcdir="${src.dir}" destdir="build/classes">
            <classpath refid="classpath"/> 
            <javac source="1.6" target="1.6" debug="on" />
Comment 1 ynb 2008-03-14 22:41:57 UTC
Previously suggested build.xml didn't incorporate groovy compilation into the default "netbeans" task and for osme
reaosn I had to rebuild groovy-containing modules after each NB restart.
Attached are build.xml and groovy-compile-impl.xml that replace standard "compile" target that used javac with similar
that uses groovyc (so all java files in the module are compile by javac but through groovyc).
I put groovy-compile-impl.xml into NB Suite's nbproject, not into module's nbproject and build.xml is for an individual
It works much better now.
Comment 2 ynb 2008-03-14 22:43:31 UTC
Created attachment 58415 [details]
an example of build.xml for a single Nb Module project
Comment 3 ynb 2008-03-14 22:44:53 UTC
Created attachment 58416 [details]
"compile" task that uses groovyc instead of javac, it just overrides the standard one from common.xml
Comment 4 ynb 2008-03-16 19:36:33 UTC
Created attachment 58456 [details]
respect JVM set in; added do-test-build task which overrrides the standard one to support groovy unit tests
Comment 5 martin_adamek 2008-03-16 20:15:49 UTC
Thanks for all the tips. I will look at it.
Comment 6 Jesse Glick 2009-03-02 15:52:48 UTC
Some tips in above URL, not sure if this can be closed or what.
Comment 7 staypufd 2010-01-12 18:25:24 UTC
In doing the example from Geertjan's blog concerning using Groovy to do NetBeans Platform work (found here:, there are still the problems that this bug talks about. I'd like to see this fixed for 6.9 so that those of us who want to use Groovy to do Platform work can finally have it integrated in a supported way.

The issues as I understand them are:
1)  The build process still doesn't include Groovy code as a possible language for use in a Platform app
2)  Even if you add the target talked about in the blog entry, the resulting classes that are built are not added to the jar file produced by the build
3)  The package is not added as a possible choice to the list of public packages in the Modules Properties GUI -> API Versioning section.  (This is even if you go add it explicitly to project.xml as a public package!)
4)  To get the resulting Groovy classes to be not only visible publicly but also included in the jar for the module, you must put in some kind of regular java code.  I did this by creating a class called 'ForcePublicPackageToBeVisible' as a big red flag name mainly out of frustration.

While using Geertjan's code and figuring out how to force the class to be visible and put in the jar is a workaround, it sure would be great to finally have Groovy really be usable as a programming language for Platform projects. It seems that fixing it for Groovy would also possibly create the framework for fixing it for all JVM based languages and finally make Platform itself polyglot capable, which I see as a huge thing.

Thanks for considering this and I hope it gets into 6.9.


Sam Griffith

My build.xml and project.xml file just in case it helps.

My build.xml file for my module:

<?xml version="1.0" encoding="UTF-8"?>
<!-- You may freely edit this file. See harness/README in the NetBeans platform -->
<!-- for some information on what you could do (e.g. targets to override). -->
<!-- If you delete this file and reopen the project it will be recreated. -->
<project name="org.kitsinc.domainModel" default="netbeans" basedir=".">
    <description>Builds, tests, and runs the project org.kitsinc.domainModel.</description>
    <import file="nbproject/build-impl.xml"/>

    <taskdef name="groovyc"

<target name="netbeans-extra">
    <groovyc srcdir="${src.dir}" destdir="${build.classes.dir}">
        <classpath refid="cp"/>
        <javac includes="*.java"/>
    <jarwithmoduleattributes jarfile="${cluster}/${module.jar}"
           compress="${build.package.compress}" index="${build.package.index}"
           manifest="${}" stamp="${cluster}/.lastModified">
        <fileset dir="${build.classes.dir}"/>


My project.xml file for my module:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="">
        <data xmlns="">

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo