Creating a simple headless build system for OpenESB projects.

(btw: This also applies to the JBI aspects of Java CAPS 6)

OK, let's face it, NetBeans is a great tool for working with your OpenESB projects; creating, compiling, testing etc. but once your project reaches a certain size it just becomes too unwieldy to open projects, build gather all the built artifacts, deploy and so on.
What you really need is some sort of scripted, headless build. I needed one, so i decided to see what could be done with a bit of Ant wrapper magic.

Enter, Ant.

I've never been much of a fan of a lot of the build systems that are imposed by the different vendors IDEs. I've never seen why I should use an IDE to build my code. A while ago, I think it was changed with NetBeans 4.x, they scrapped the existing build system and introduced Ant. NetBeans' build system is 100% Ant based. In theory this should make it possible for me to just fire up a project's build.xml file directly from the command line for any project generated within NetBeans, OpenESB projects as well.  In practice it is, but with a few small caveats.

OpenESB introduces a lot of plug-ins for NetBeans along with their associated Ant extensions. These can be used for CLI building and deployment.

In this blog post I'll describe how to start building OpenESB projects from the command-line and how to make the "behind-the-scenes magic" that NetBeans hide from you work from the command line as well.

But, first of all; a successful build system requires a lot of structuring of code.
My team uses Subversion as the SCM for the project I'm currently involved in. Subversion best practices introduce a few things that can be troublesome when you have to take into account the possibility of developing with multiple branches, tags etc. in NetBeans. (My SCM organization thoughts might be the subject of a post at some later time..)
Anyway, Subversion has the notion of named directories for tags, branches and trunk.
So a structure such as this might be created:
Project name
->branches
->tags
->trunk
-->NetBeans Project A
 -->NetBeans Project Project B


Initially we thought that an organization where our source tree was grouped on three main levels was a good idea:
Composite Applications
->CA1
-->branches
-->tags
-->trunk
->CA2
Service Units
->SU1
-->branches
-->tags
-->trunk
->SU2
-->branches
-->tags
-->trunk
Java

This proved to be somewhat hard to work with, because of the way that NetBeans references dependent projects. If we wanted the the CA to reference a SU or an EJB (in the Java directory) we would get the tag name or trunk denomination in all sorts of project related files and paths would become unusable as soon as we introduced a tag or branch.

So we went back to the drawing board and decided to create a more module like structure.
Module1
->branches
->tags
->trunk
--->CA1
--->CA2
--->SU1
--->SU2
Module2
->branches
->tags
->trunk
--->CA1
--->SU1
Module3
->branches
->tags
->trunk
JavaModule
->branches
->tags
->trunk

A courser structure, but sometimes you trade flexibility for practicality.

A module contains code for a particular domain of the business problem.
Modules that require relations to other modules are resolved through the use of the svn:externals tag on the branches/tags/trunk directory. This physically copies a version of the required module into the directory of the module that requires it. At the expense of disk space we hence got rid of the branches/tags/trunk bits of all file paths.
We now have a flat structure:

Module1
->branches
->tags
->trunk
-->CA1
-->SU1
-->SU2
-->JavaModule (svn:externals the version of the JavaModule which resides on the same level as the Module1)

JavaModule
->branches
->tags
->trunk
---> MessageDrivenEJB

All project relations are now in a flat structure making it easy to reference and build. Checkout is also easy, you get what is required to build a module.
In addition to Ant CAs, SUs and Java projects I also created some utility modules.
I created a CommonScripts module:
CommonScripts
->branches
->tags
->trunk
Module1
->branches
->tags
->trunk
Module2
->branches
->tags
->trunk

A version of the CommonScripts module is referenced by the other modules (svn:externals again)
Doing a svn up(date) gives me (for a Module)
Module1
->branches
->tags
->trunk
-->CommonScripts
-->CA1
-->SU1
-->SU2
-->Java module

I wanted to avoid changing the NetBeans generated build.xml and nbproject/build-impl.xml files, and at the same time remove the need for the nbproject/private/private.properties file. This file has a lot of file paths, JDK setting for build etc. stuff in it that are not relevant for all environments that you need to build in. (Developers may have the code in different places or different OS's hence the need to create specific wrappers or stubs to substitute this.)

CommonScripts module.

This module contains all wrappers and scripts that are required to build all projects in a module. It also creates some environment specific property files that replace the use of nbproject/private/private.properties)
In my setup this module is shared among all modules, no module specifics are in it, just generic build wrappers and environment properties files.
In here I've created a file environment.properties that just sets stuff like the location of GlassFish and NetBeans.
(Note! I might be wrong but I think that you need a NetBeans distribution to build the projects, however NetBeans requires a GUI to install and run. Solution: tar up your NetBeans install, ftp to the headless build server, untar it. You just need the Jar files and their structures that ship with NetBeans and the SOA plug ins.)
Contents of the environment.properties file:

glassfish.home=C:/openesb20080603/glassfish-v2-ur2-b04-patch-20080603
caps.netbeans.home=C:/openesb20080603/NetBeans-6.1-build-200806030105

deploy.host=localhost
deploy.port=4848

#alternatives are server,domain, <cluster-name>, <instance-name>
#see http://wiki.open-esb.java.net/Wiki.jsp?page=JbiDeployServiceAssemblyTask
deploy.target=server

deploy.username=admin
deploy.password.file=../CommonScripts/passwd


I've also got a .bat file (for Windows, for Unix use what's appropriate for your shell) to set the build environment in here:

set ANT_HOME=C:\\openesb20080603\\NetBeans-6.1-build-200806030105\\java2\\ant
set caps.netbeans.home=C:\\openesb20080603\\NetBeans-6.1-build-200806030105
set netbeans.home=%caps.netbeans.home%\\platform8
set JAVA_HOME=C:\\Java\\jdk1.5.0_15
set PATH=%ANT_HOME%\\bin;%JAVA_HOME%\\bin;%PATH%
set from.commandline=true


Now then; here comes the real trick:

How to let Ant know of what's in nbproject/private/private.properties for the environment, especially if you haven't got one?
Easy, create your own!
I've created a little template file here with the relevant resolving of the properties that the build.xml/build-impl.xml files require.

caps.netbeans.home=@CAPS_NETBEANS_HOME@
caps.netbeans.user=.
netbeans.home=@CAPS_NETBEANS_HOME@/platform8
from.commandline=true
no.javadoc.preview=true
no.netbeans.home=true
glassfish.home=@GLASSFISH_HOME@

j2ee.platform.classpath=@GLASSFISH_HOME@/lib/javaee.jar;@GLASSFISH_HOME@/lib/jsf-impl.jar;@GLASSFISH_HOME@/lib/activation.jar;@GLASSFISH_HOME@/lib/appserv-tags.jar;@GLASSFISH_HOME@/lib/mail.jar;@GLASSFISH_HOME@/lib/appserv-jstl.jar;@GLASSFISH_HOME@/lib/webservices-tools.jar;@GLASSFISH_HOME@/lib/webservices-rt.jar;@GLASSFISH_HOME@/lib/appserv-ws.jar

j2ee.platform.wscompile.classpath=@GLASSFISH_HOME@/lib/j2ee.jar;@GLASSFISH_HOME@/lib/saaj-api.jar;@GLASSFISH_HOME@/lib/saaj-impl.jar;@GLASSFISH_HOME@/lib/jaxrpc-api.jar;@GLASSFISH_HOME@/lib/jaxrpc-impl.jar;@GLASSFISH_HOME@/lib/endorsed/jaxp-api.jar;@GLASSFISH_HOME@/lib/appserv-ws.jar;@GLASSFISH_HOME@/lib/webservices-tools.jar;@GLASSFISH_HOME@/lib/webservices-rt.jar

j2ee.platform.wsgen.classpath=@GLASSFISH_HOME@/lib/webservices-tools.jar;@GLASSFISH_HOME@/lib/webservices-rt.jar;@GLASSFISH_HOME@/lib/tools.jar;@GLASSFISH_HOME@/lib/appserv-jstl.jar;@GLASSFISH_HOME@/lib/javaee.jar;@GLASSFISH_HOME@/lib/appserv-ws.jar;@GLASSFISH_HOME@/lib/mail.jar;@GLASSFISH_HOME@/lib/activation.jar

j2ee.platform.wsimport.classpath=@GLASSFISH_HOME@/lib/webservices-tools.jar;@GLASSFISH_HOME@/lib/webservices-rt.jar;@GLASSFISH_HOME@/lib/tools.jar;@GLASSFISH_HOME@/lib/appserv-jstl.jar;@GLASSFISH_HOME@/lib/javaee.jar;@GLASSFISH_HOME@/lib/appserv-ws.jar;@GLASSFISH_HOME@/lib/mail.jar;@GLASSFISH_HOME@/lib/activation.jar

jaxbwiz.xjcdef.classpath=@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/activation.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jaxb-api.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-impl.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-xjc.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jsr173_api.jar
jaxbwiz.xjcrun.classpath=@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/activation.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jaxb-api.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-impl.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-xjc.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jsr173_api.jar
jaxbwiz.gensrc.classpath=@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/activation.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jaxb-api.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-impl.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-xjc.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jsr173_api.jar
libs.jaxb21.classpath=@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/activation.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jaxb-api.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-impl.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/jaxb-xjc.jar;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api/jsr173_api.jar
jaxbwiz.endorsed.dirs=@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21/api;@CAPS_NETBEANS_HOME@/java2/modules/ext/jaxws21

libs.junit_4.classpath=@CAPS_NETBEANS_HOME@/java2/modules/ext/junit-4.1.jar

module.install.dir=@CAPS_NETBEANS_HOME@/soa2/modules
enterprise.module.install_dir=@CAPS_NETBEANS_HOME@/enterprise5/modules
ide.module.install.dir=@CAPS_NETBEANS_HOME@/ide9/modules
java.module.install.dir=@CAPS_NETBEANS_HOME@/java2/modules
soa.module.install.dir=@CAPS_NETBEANS_HOME@/soa2/modules
xml.module.install.dir=@CAPS_NETBEANS_HOME@/xml2/modules

the @SOMETHING@ syntax in this file is replaced with an Ant task that generates an environment specific properties file based on what's in CommonScripts/environment.properties.
Small Ant snippet for it:
        <!-- creates a property file for the environment -->
    <target name="create_property_file" if="isWindowsPlatform" depends="configOS">
        <property file="environment.properties"/>
        <delete file="build_win.properties"/>

        <filter token="CAPS_NETBEANS_HOME" value="${caps.netbeans.home}"/>
        <filter token="GLASSFISH_HOME" value="${glassfish.home}"/>
        <copy file="build_win.properties.template" tofile="build_win.properties" filtering="true"/>
    </target>

I've made a template file for the different OS architectures, though it would probably be enough with just one file.

Now when doing the build, include the generated property file using the -propertyfile argument with ant.
ant -f ..\\scripts\\buildmodule.xml build.module -propertyfile build_win.properties %1 %2 %3

Notice in the line above that it refers to a scripts directory.
Module1
->branches
->tags
->trunk
-->CommonScripts  (through svn:externals)
-->CA1
-->SU1
-->SU2
-->Java module
-->scripts

This directory contains the module specific build script wrappers. These start the build of the CAs, SUs in the order specified in the scripts.

The scripts directory:
-->scripts
--->buildmodule.properties
--->buildmodule.xml
--->deploymodule.properties
--->deploymodule.xml

The buildmodule.properties file contains references to the projects built, Ant scrips and targets called by the buildmodule.xml file
A small Ant wrapper delegates to the build.xml file for the SU, CA or Java project in the module:

    <target name="execute.ant.target">
        <echo message="Executing build on:  ${internal.path}"/>
        <echo message="Buildfile:           ${internal.buildfile}"/>
        <echo message="Buildtarget:         ${internal.buildtarget}"/>

        <ant antfile="${internal.buildfile}" target="${internal.buildtarget}" dir="${internal.path}"/>
    </target>


buildmodule.xml:

    <target name="build.module">
        <antcall target="execute.ant.target">
            <param name="internal.path" value="${EJB.path}"/>
            <param name="internal.buildfile" value="${EJB.buildfile}"/>
            <param name="internal.buildtarget" value="${EJB.buildtarget}"/>
        </antcall>   

        <antcall target="execute.ant.target">
            <param name="internal.path" value="${SU.path}"/>
            <param name="internal.buildfile" value="${SU.buildfile}"/>
            <param name="internal.buildtarget" value="${SU.buildtarget}"/>
        </antcall>           

        <antcall target="execute.ant.target">
            <param name="internal.path" value="${CA.path}"/>
            <param name="internal.buildfile" value="${CA.buildfile}"/>
            <param name="internal.buildtarget" value="${CA.buildtarget}"/>
        </antcall>       


Now, in order to do a full build traverse to the CommonScripts directory. Set the environment for Ant.
And do:
ant -f ..\\scripts\\buildmodule.xml build.module -propertyfile build_win.properties

Cleanup is also easy:
ant -f ..\\scripts\\buildmodule.xml build.module -propertyfile build_win.properties -Dinternal.buildtarget=clean
Setting the -D switch on the command line overrides what Ant loads, so it assigns ${internal.buildtarget} the value "clean"

Deployment follows the exact same pattern, but just calls a thin wrapper around the $glassfish.home/bin/asadmin tool invoking the "deploy.jbi.service.assembly" command for service assemblies.


Comments:

There is an easier way to replace the private.properties file. build-impl.xml does not require the file itself. It only requires that the properties are set.

To achieve this, we have created two properties file: The first one contains the platform specific properties (the ones you have placed in your batch file). The second one is similar to your template. But instead of copying the file and replacing the strings, we directly reference the platform specific properties.

environment-buildserver.properties:
caps.netbeans.home=/opt/netbeans-6.1

environment.properties:
netbeans.home=${caps.netbeans.home}/platform8

In our build file, we simply read in both property files:
<property file="environment-buildserver.properties"/>
<property file="environment.properties"/>

The nice thing about this setup is that you can place all your platform specific files in the CommonScripts directory. You can then select which file to load automatically.

Posted by Thomas on March 04, 2009 at 04:55 AM CET #

Thanks Thomas for your comment, perhaps I should clarify that my file with platform specific properties is not the nbproject/private/private.properties file. my file is still housed in CommonScripts. and loaded by my wrapping script for the project's ant files.

Posted by Trond Stromme on March 09, 2009 at 06:37 AM CET #

Please note that starting from NetBeans 6.5.1, there is some change in SOA projects' command-line build system:

(1) rename "caps.netbeans.home" to "esb.netbeans.home";

(2) do not define "netbeans.home".

See http://www.netbeans.org/issues/show_bug.cgi?id=162215 for more info.

Posted by Jun Qian on May 19, 2009 at 03:58 PM CEST #

Hello Trond!

I'm trying to manage builds of JCAPS 6 from command line. I've followed the suggestions at this blog, but have now reached a problem. When building a jbi componenent which invokes <validate-project buildDirectory="${basedir}/${build.dir}" sourceDirectory="${basedir}/${src.dir}" projectClassPath="${javac.classpath}" buildDependentProjectDir="${basedir}/${build.dir}/dependentProjectFiles" classpathRef="ant.task.classpath" allowBuildWithError="${allow.build.with.error}" validation="${validation}"/> I'm getting the following error when compiling from command line:

[validate-project] java.lang.reflect.InvocationTargetException
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[validate-project] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[validate-project] at java.lang.reflect.Method.invoke(Method.java:597)
[validate-project] at org.netbeans.modules.bpel.project.anttasks.cli.CliValidateBpelProjectTask.execute(CliValidateBpelProjectTask.java:154)
[validate-project] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[validate-project] at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
[validate-project] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[validate-project] at java.lang.reflect.Method.invoke(Method.java:597)
[validate-project] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[validate-project] at org.apache.tools.ant.Task.perform(Task.java:348)
[validate-project] at org.apache.tools.ant.Target.execute(Target.java:357)
[validate-project] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[validate-project] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[validate-project] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[validate-project] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[validate-project] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
[validate-project] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[validate-project] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[validate-project] at java.lang.reflect.Method.invoke(Method.java:597)
[validate-project] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[validate-project] at org.apache.tools.ant.Task.perform(Task.java:348)
[validate-project] at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:62)
[validate-project] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[validate-project] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[validate-project] at java.lang.reflect.Method.invoke(Method.java:597)
[validate-project] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[validate-project] at org.apache.tools.ant.Task.perform(Task.java:348)
[validate-project] at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:391)
[validate-project] at net.sf.antcontrib.logic.ForTask.doSequentialIteration(ForTask.java:259)
[validate-project] at net.sf.antcontrib.logic.ForTask.doToken(ForTask.java:268)
[validate-project] at net.sf.antcontrib.logic.ForTask.doTheTasks(ForTask.java:299)
[validate-project] at net.sf.antcontrib.logic.ForTask.execute(ForTask.java:244)
[validate-project] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[validate-project] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[validate-project] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[validate-project] at java.lang.reflect.Method.invoke(Method.java:597)
[validate-project] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[validate-project] at org.apache.tools.ant.Task.perform(Task.java:348)
[validate-project] at org.apache.tools.ant.Target.execute(Target.java:357)
[validate-project] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[validate-project] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[validate-project] at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[validate-project] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[validate-project] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[validate-project] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[validate-project] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[validate-project] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[validate-project] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
[validate-project] Caused by: java.lang.StackOverflowError

I've seen on Nabble that you seemed to have a similiar problem. Have you solved that or found any nice workaround?

Posted by Marcus Högberg on June 11, 2009 at 08:38 AM CEST #

I had the same problem (netbeans 6.7.1).

Any suggestions please?

I got past the validate-project, by commenting out that section in the build-impl, but I got similar thing on almost the next line:

$ ant -Desb.netbeans.home=/usr/local/netbeans-6.7.1
Buildfile: build.xml

do-dist:
No protocol specified
[generate-jbi-xml] java.lang.reflect.InvocationTargetException
[generate-jbi-xml] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[generate-jbi-xml] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[generate-jbi-xml] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[generate-jbi-xml] at java.lang.reflect.Method.invoke(Method.java:616)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliGenerateJbiDescriptorTask.execute(CliGenerateJbiDescriptorTask.java:107)
[generate-jbi-xml] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[generate-jbi-xml] at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
[generate-jbi-xml] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[generate-jbi-xml] at java.lang.reflect.Method.invoke(Method.java:616)
[generate-jbi-xml] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[generate-jbi-xml] at org.apache.tools.ant.Task.perform(Task.java:348)
[generate-jbi-xml] at org.apache.tools.ant.Target.execute(Target.java:357)
[generate-jbi-xml] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[generate-jbi-xml] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
[generate-jbi-xml] at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
[generate-jbi-xml] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[generate-jbi-xml] at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
[generate-jbi-xml] at org.apache.tools.ant.Main.runBuild(Main.java:758)
[generate-jbi-xml] at org.apache.tools.ant.Main.startAnt(Main.java:217)
[generate-jbi-xml] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[generate-jbi-xml] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
[generate-jbi-xml] Caused by: java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
[generate-jbi-xml] at java.lang.Class.forName0(Native Method)
[generate-jbi-xml] at java.lang.Class.forName(Class.java:186)
[generate-jbi-xml] at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
[generate-jbi-xml] at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:106)
[generate-jbi-xml] at java.lang.Class.forName0(Native Method)
[generate-jbi-xml] at java.lang.Class.forName(Class.java:186)
[generate-jbi-xml] at java.awt.Toolkit$2.run(Toolkit.java:849)
[generate-jbi-xml] at java.security.AccessController.doPrivileged(Native Method)
[generate-jbi-xml] at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:841)
[generate-jbi-xml] at sun.swing.SwingUtilities2$AATextInfo.getAATextInfo(SwingUtilities2.java:131)
[generate-jbi-xml] at javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(MetalLookAndFeel.java:1564)
[generate-jbi-xml] at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(BasicLookAndFeel.java:147)
[generate-jbi-xml] at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLookAndFeel.java:1599)
[generate-jbi-xml] at javax.swing.UIManager.setLookAndFeel(UIManager.java:545)
[generate-jbi-xml] at javax.swing.UIManager.setLookAndFeel(UIManager.java:585)
[generate-jbi-xml] at javax.swing.UIManager.initializeDefaultLAF(UIManager.java:1334)
[generate-jbi-xml] at javax.swing.UIManager.initialize(UIManager.java:1421)
[generate-jbi-xml] at javax.swing.UIManager.maybeInitialize(UIManager.java:1409)
[generate-jbi-xml] at javax.swing.UIManager.getDefaults(UIManager.java:659)
[generate-jbi-xml] at javax.swing.filechooser.FileSystemView.getFileSystemView(FileSystemView.java:80)
[generate-jbi-xml] at org.netbeans.modules.masterfs.filebasedfs.utils.FileInfo.<clinit>(FileInfo.java:53)
[generate-jbi-xml] at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.getInstance(FileObjectFactory.java:104)
[generate-jbi-xml] at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.getInstance(FileObjectFactory.java:99)
[generate-jbi-xml] at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.<init>(FileBasedFileSystem.java:82)
[generate-jbi-xml] at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.<clinit>(FileBasedFileSystem.java:72)
[generate-jbi-xml] at org.netbeans.modules.masterfs.filebasedfs.FileBasedURLMapper.getFileObjects(FileBasedURLMapper.java:128)
[generate-jbi-xml] at org.netbeans.modules.masterfs.MasterURLMapper.getFileObjects(MasterURLMapper.java:62)
[generate-jbi-xml] at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:213)
[generate-jbi-xml] at org.netbeans.modules.projectapi.SimpleFileOwnerQueryImplementation.uri2FileObject(SimpleFileOwnerQueryImplementation.java:305)
[generate-jbi-xml] at org.netbeans.modules.projectapi.SimpleFileOwnerQueryImplementation.getOwner(SimpleFileOwnerQueryImplementation.java:89)
[generate-jbi-xml] at org.netbeans.api.project.FileOwnerQuery.getOwner(FileOwnerQuery.java:147)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliBpelCatalogModel.collectCatalogXmlRecursively(CliBpelCatalogModel.java:177)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliBpelCatalogModel.getModelSource(CliBpelCatalogModel.java:105)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliBpelCatalogModel.getBPELModel(CliBpelCatalogModel.java:272)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.processFile(CliJbiGenerator.java:471)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.processFileObject(CliJbiGenerator.java:446)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.processFolder(CliJbiGenerator.java:454)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.processFileObject(CliJbiGenerator.java:444)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.processSourceDir(CliJbiGenerator.java:497)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.processSourceDirs(CliJbiGenerator.java:492)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.process(CliJbiGenerator.java:124)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliJbiGenerator.generate(CliJbiGenerator.java:130)
[generate-jbi-xml] at org.netbeans.modules.bpel.project.anttasks.cli.CliGenerateJbiDescriptorDelegate.execute(CliGenerateJbiDescriptorDelegate.java:91)
[generate-jbi-xml] ... 21 more

Posted by Martin Jenkins on March 10, 2010 at 05:40 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog will be about software that i work with; Java, OpenESB, GlassFish and perhaps a bit about photography.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today