Java


(ubuntu 9.04 gnome, netbeans 6.5, Java 1.6)

I assume you are familiar with: FaqNetbeansConf , Change the Font Size .

Setting the font size of your editors is easy : Tools – Options – Font and Colors .

If you want to change font size of the menues and panels of the GUI and you are using startup options

--laf javax.swing.plaf.metal.MetalLookAndFeel

you can set the GUI font size:

--fontsize 13

and it will work without any problems.

In case you are using the default GTK Theme you will find that the last option doesn’t change the font size of the menues. Here it helps to edit the ~/.gtkrc-2.0 configuration file:

# This file was written by KDE
# You can edit it in the KDE control center, under "GTK Styles and Fonts"

include "/usr/share/themes/Qt/gtk-2.0/gtkrc"

style "user-font"
{
	font_name="Verdana 11"
}
widget_class "*" style "user-font"

gtk-theme-name="Qt"
gtk-font-name="Verdana 11"

Change entries like “Verdana 11″ according to your needs.

(ant 1.7, pmd 4.2.4)

I’ve recently tried to use PMD – sourcecode inspection tool in an ant powered build. Here is a basic example from a test in the build.xml of a Netbeans project (the pmd jar is located in ant’s home lib directory):

    <target name="pmd" depends="init">
         <!-- see http://pmd.sourceforge.net/ant-task.html -->
        <taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"/>
        <mkdir dir="${build.test.results.dir}"/>
        <pmd targetjdk="1.6">
            <!-- auxClasspath> 
               <pathelement location="dist/test.jar" /> 
            </auxClasspath -->
            <ruleset>basic</ruleset>
            <!-- ruleset>rulesets/basic.xml</ruleset -->
            <!-- ruleset>rulesets/braces.xml</ruleset>
            <ruleset>rulesets/javabeans.xml</ruleset>
            <ruleset>rulesets/unusedcode.xml</ruleset>
            <ruleset>rulesets/strings.xml</ruleset>
            <ruleset>rulesets/design.xml</ruleset>
            <ruleset>rulesets/coupling.xml</ruleset>
            <ruleset>rulesets/codesize.xml</ruleset>
            <ruleset>rulesets/imports.xml</ruleset>
            <ruleset>rulesets/naming.xml</ruleset -->
            <formatter type="xml" toFile="${build.test.results.dir}/pmd_report.xml" />
            <fileset dir="${src.dir}">
                <include name="**/*.java" />
            </fileset>
        </pmd>
    </target>

More examples you will find at PMD Ant Task.

Running this task from command line ant -v pmd gives a warning

[pmd] Could not find class test.hallo.Main

or running same from Netbeans (using external ant).

Could not find class test.hallo.Main
java.lang.NoClassDefFoundError: org/jaxen/JaxenException
at net.sourceforge.pmd.rules.XPathRule.getRuleChainVisits(XPathRule.java:87)

After looking around for a while I found this thread Ant could not find class.

Citation from there:

As far as what this will do to the PMD results… these errors come from the Type Resolution code. Only Rules which use the Type resolution capabilities even have a chance to give less than accurate results, and then only in circumstances requiring type information not apparent from the .java file directly. Finally, there only a few Rules in PMD that actively use Type Resolution right now, although I know several folks have written custom Rules using this capability.

Solution?

PMD 5 is not out yet. But I was successful by using the latest snapshot (at time of writing)
pmd-5.0-20081231.082852-77.jar. Also, I had to change the target definition a little:

 <target name="pmd" depends="init">
        <taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"/>
        <mkdir dir="${build.test.results.dir}"/><!-- wird auch in -pre-test-run aufgerufen -->
        <pmd>
            <auxClasspath> 
               <pathelement location="dist/test.jar" /> 
            </auxClasspath>
<!-- new path for rulesets!! -->
            <ruleset>rulesets/java/basic.xml</ruleset>
            <formatter type="xml" toFile="${build.test.results.dir}/pmd_report.xml" />
            <fileset dir="${src.dir}">
                <include name="**/*.java" />
            </fileset>
        </pmd>
    </target>

Now it’s working.

(netbeans 6.1, external ant 1.7)

Here is a code snippet from build.xml which shows a possible way to customize your build in Netbeans by providing a version number and including it into the MANIFEST.MF of the created distribution jar. The current property version will be stored in a version.properties file. This version number will be retrieved and written back to the file. The script knows then the new version number (custom.version.property) and uses it in the jar creation task (see also Adaptation of Netbeans Ant Build for Integration – CopyLibs Issue).

Dealing with version number:

  <!--
                =================
                Set Version Related
                =================
     -->
     <!-- watch out! if you put version.properties file to src dirs,
     cause the file ist copied 
     to build before it is touched by this tasks, 
     you will probably need to do some further customization -->
     <property name="custom.version.file" value="${basedir}/version.properties"/>
    <target name="-post-init">
        <!-- check if there is a version -->
        <available file="${custom.version.file}" property="custom.version.available"/>
    </target>
    <target name="pre-inc-version" depends="init"  unless="custom.version.available">
        <echo message="No version file found. Creating ${custom.version.file} with Initial Version 0."/>
        <echo file="${custom.version.file}" message="version=0"/>
    </target>
     <target name="inc-version" depends="pre-inc-version">
         <!-- increment version number -->
        <propertyfile file="${custom.version.file}">
            <entry key="version" value="1" type="int" operation="+"/>
        </propertyfile>
        <!-- read version -->
        <property file="${custom.version.file}" prefix="custom"/>
        <echo message="project ${ant.project.name} released with version ${custom.version}" />
    </target>
    <target name="-pre-jar" depends="inc-version">
        <!-- Empty placeholder for easier customization. -->
        <!-- You can override this target in the ../build.xml file. -->
    </target>
    <target name="clean-version" depends="-do-clean" description="Remove version property file">
        <delete file="${custom.version.file}"/>
    </target>

(You could also use ant BuildNumber task.)

Using the version number in jar file creation:

<!--
                =================
                Jar Overriding Default
                =================
     -->
     <target depends="init,compile,-pre-jar,-post-jar" description="Custom Build JAR with libs and version. See -do-jar-with-libs." name="jar">
        <property location="${build.classes.dir}" name="build.classes.dir.resolved"/>
        <echo message="-------------run.classpath------- ${run.classpath}"/>
        <echo message="--------- build.classes.dir.resolved ------ ${build.classes.dir.resolved}"/>
        <pathconvert property="run.classpath.without.build.classes.dir">
            <path path="${run.classpath}"/>
            <map from="${build.classes.dir.resolved}" to=""/>
        </pathconvert>
        <echo message="-------- run.classpath.without.build.classes.dir ---- ${run.classpath.without.build.classes.dir}"/>
        <pathconvert pathsep=" " property="jar.classpath">
            <path path="${run.classpath.without.build.classes.dir}"/>
            <chainedmapper>
                <flattenmapper/>
                <globmapper from="*" to="lib/*"/>
            </chainedmapper>
        </pathconvert>
        <echo message="--- build.classes.dir --- ${build.classes.dir}" />
        <copy todir="${dist.dir}/lib" flatten="true">
            <path>
                <pathelement path="${run.classpath.without.build.classes.dir}"/>
            </path>
        </copy>
        <j2seproject1:jar manifest="${manifest.file}">
            <j2seproject1:manifest>
                <j2seproject1:attribute name="Main-Class" value="${main.class}"/>
                <j2seproject1:attribute name="Class-Path" value="${jar.classpath}"/>
                <j2seproject1:attribute name="Build-Version" value="${custom.version}" />
            </j2seproject1:manifest>
        </j2seproject1:jar>
        <echo>To run this application from the command line without Ant, try:</echo>
        <property location="${dist.jar}" name="dist.jar.resolved"/>
        <echo>java -jar "${dist.jar.resolved}"</echo>
    </target>

(Netbeans 6.1, external ant 1.7 )

If you create a standalone Java application project (i.e. one that comes with all used external jars and libs included, so there are copied to dist/lib) in Netbeans, commit the changes to version control, checkout or update the changes to your test and integration server and try to build the same project there, you might run into problems even if you used an external ant for building the same project in Netbeans on your local machine. (Look here for an explanation why jars are not includeable in the distribution jar itself.)

On the integration server the libs will not be copied to the dist/lib folder. The reason is that Netbeans is using an own ant task org.netbeans.modules.java.j2seproject.copylibstask which extends import org.apache.tools.ant.taskdefs.Jar and this jar will just not be found on the integration server except you completly reconstruct your local build environment on the integration server, what will be difficult if you are using a CI system (in my case it’s hudson). So let’s have a closer look at this issue and some possible solutions:

There are two principal ant build files Netbeans is using during the build process: build.xml – user can edit this file, build-impl.xml – user should not edit this one. Also have a look at this post Visualizing Default Ant Task Dependencies for Netbeans build-impl.xml.

Where and when the Libs are copied to dist/lib by the CopyLibs task?

For that we have to look into build-impl.xml. The libs are copied when the jar target ist executed:

 <target 
depends="init,compile,-pre-jar,-do-jar-with-manifest,-do-jar-without-manifest,-do-jar-with-mainclass,-do-jar-with-libraries,-post-jar"
description="Build JAR." 
name="jar"/>

There are several jar related tasks, which are executed when certain conditions are valid, that means certain variables are set. The interesting task here is -do-jar-with-libraries:

 <target depends="init,compile,-pre-pre-jar,-pre-jar" 
if="manifest.available+main.class+mkdist.available" 
name="-do-jar-with-libraries">

This task will be executed if property manifest.available+main.class+mkdist.available is set. Especially if the path to CopyLibs is set.

        <condition property="manifest.available+main.class+mkdist.available">
            <and>
                <istrue value="${manifest.available+main.class}"/>
                <isset property="libs.CopyLibs.classpath"/>
            </and>
        </condition>

Where does this path comes from. It is read in

    <target depends="-pre-init,-init-private,-init-libraries" name="-init-user">
        <property file="${user.properties.file}"/>

For example from: .netbeans/6.1/build.properties.
libs.CopyLibs.classpath=/home/user/bin/netbeans/java2/ant/extra/org-netbeans-modules-java-j2seproject-copylibstask.jar
libs.CopyLibs.javadoc=
libs.CopyLibs.maven-pom=
libs.CopyLibs.src=

That’s a problem! The build.properties file will not be found on the integration server, the properties libs.CopyLIbs.classpath and manifest.available+main.class+mkdist.available will not be set, the task -do-jar-with-libraries will not be executed.

What do you need CopyLibs task for?

Look at how the task is used (I included some echos for better understanding):

<target depends="init,compile,-pre-pre-jar,-pre-jar" if="manifest.available+main.class+mkdist.available" name="-do-jar-with-libraries">
        <property location="${build.classes.dir}" name="build.classes.dir.resolved"/>
        <echo message="-------------run.classpath------- ${run.classpath}"/><echo message="--------- build.classes.dir.resolved ------ ${build.classes.dir.resolved}"/>
        <pathconvert property="run.classpath.without.build.classes.dir">
            <path path="${run.classpath}"/>
            <map from="${build.classes.dir.resolved}" to=""/>
        </pathconvert>
        <echo message="-------- run.classpath.without.build.classes.dir ---- ${run.classpath.without.build.classes.dir}"/>
        <pathconvert pathsep=" " property="jar.classpath">
 
            <path path="${run.classpath.without.build.classes.dir}"/>
            <chainedmapper>
                <flattenmapper/> <target depends="init,compile,-pre-pre-jar,-pre-jar" if="manifest.available+main.class+mkdist.available" name="-do-jar-with-libraries">
                <globmapper from="*" to="lib/*"/>
            </chainedmapper>
        </pathconvert>
        <taskdef classname="org.netbeans.modules.java.j2seproject.copylibstask.CopyLibs" classpath="${libs.CopyLibs.classpath}" name="copylibs"/>
        <copylibs compress="${jar.compress}" jarfile="${dist.jar}" manifest="${manifest.file}" runtimeclasspath="${run.classpath.without.build.classes.dir}">
            <fileset dir="${build.classes.dir}"/>
            <manifest>
                <attribute name="Main-Class" value="${main.class}"/>
                <attribute name="Class-Path" value="${jar.classpath}"/>
            </manifest>
        </copylibs>
        <echo>To run this application from the command line without Ant, try:</echo>
        <property location="${dist.jar}" name="dist.jar.resolved"/>
        <echo>java -jar "${dist.jar.resolved}"</echo>
    </target>

and then study the java code. So not much problems here. Mainly copying some files and using standard jar functions, also providing some README file. Below I will show how you can workaround using this task.

Solutions?

First, you could copy the CopyLibs Task jar somewhere and set the property libs.CopyLibs.classpath in your build.xml to the appropriate location or use project.properties file which comes with the Netbeans build scripts. There are little chances that this task will change and you will have to update the CopyLibs Task jar.

Second, you could build your standalone application using One-JAR overriding the jar target from build-impl.xml.

Third, don’t change build structure but avoid using CopyLibs task. Here is an example how to change build.xml:

First make macrodefs and presetdefs from build-impl.xml callable by declaring appropriate namespaces in build.xml:

<project name="Test" default="default" basedir="."
xmlns:j2seproject1="http://www.netbeans.org/ns/j2se-project/1"
xmlns:j2seproject3="http://www.netbeans.org/ns/j2se-project/3">
    <description>Builds, tests, and runs the project Test.</description>

Then redefine the jar target a little and override it in build.xml (echos only for feedback):

<!-- target depends="init,compile,-pre-pre-jar,-pre-jar" if="manifest.available+main.class+mkdist.available" name="-do-jar-with-libraries" -->
     <target depends="init,compile,-pre-jar,-post-jar" description="Build JAR." name="jar">
        <property location="${build.classes.dir}" name="build.classes.dir.resolved"/>
        <echo message="-------------run.classpath------- ${run.classpath}"/>
        <echo message="--------- build.classes.dir.resolved ------ ${build.classes.dir.resolved}"/>
        <pathconvert property="run.classpath.without.build.classes.dir">
            <path path="${run.classpath}"/>
            <map from="${build.classes.dir.resolved}" to=""/>
        </pathconvert>
        <echo message="-------- run.classpath.without.build.classes.dir ---- ${run.classpath.without.build.classes.dir}"/>
        <pathconvert pathsep=" " property="jar.classpath">
            <path path="${run.classpath.without.build.classes.dir}"/>
            <chainedmapper>
                <flattenmapper/>
                <globmapper from="*" to="lib/*"/>
            </chainedmapper>
        </pathconvert>
        <echo message="--- build.classes.dir --- ${build.classes.dir}" />
        <copy todir="${dist.dir}/lib" flatten="true">
            <path>
                <pathelement path="${run.classpath.without.build.classes.dir}"/>
            </path>
        </copy>
        <j2seproject1:jar manifest="${manifest.file}">
            <j2seproject1:manifest>
                <j2seproject1:attribute name="Main-Class" value="${main.class}"/>
                <j2seproject1:attribute name="Class-Path" value="${jar.classpath}"/>
                <!-- if you deal with versions -->
                <!-- j2seproject1:attribute name="Build-Version" value="${version}" / -->
            </j2seproject1:manifest>
        </j2seproject1:jar>
        <echo>To run this application from the command line without Ant, try:</echo>
        <property location="${dist.jar}" name="dist.jar.resolved"/>
        <echo>java -jar "${dist.jar.resolved}"</echo>
    </target>

… and you’ve got rid of the annoying CopyLibs task thing.

Automation for the people

Problem:Create an XML Schema which will be binded by JAXB to a class structure following certain constrains. You have certain degrees of freedom for your schema design and later you might also use schema annotations provided by JAXB. Modularize your XML schemas, simplest example is: A.xsd uses <include> to include declarations from schema B.xsd.

I want to try Netbeans’ excellent schema design features. Eventually I want to publish the schemas in a WAR deployed in a web container. That’s why I decided to put the files directly into the /web directory of the web-project.

Proposed Solution:
Trying to use Netbeans’ JAXB Wizard (or see http://wiki.netbeans.org/JAXBWizard) to create a JAXB Binding for A.xsd you will meet certain limitations: schema file changes won’t be visible to the “Regenerate” operation. You could edit the copy of A.xsd created by the JAXB Wizard in src/conf/xml-resources/jaxb/name_of_the_binding to make changes visible to the task but that will not see changes in B.xsd. The reason is that the ant tasks created by the JAXB Wizard do not provide this kind of granularity.

So the solution for me was to create the binding using JAXB Wizard, then overriding the created tasks. I copied <target name="jaxb-code-generation" ... from nbproject/xml_binding_build.xml to build.xml and customized the parameters of the XJC task:

  <import file="nbproject/build-impl.xml"/>
 
    <target name="ask-something">
    <input message="Do you like to customize the best IDE of all times?"
    validargs="Yes, Yes"
    addproperty="answer"/>
<echo message="Answer Yes! ${answer}" />
    </target>
 
     <target name="jaxb-code-generation" depends="xjc-typedef-target">
        <mkdir dir="build/generated/addons/jaxb" xmlns:s="http://xml.netbeans.org/schema/JAXBWizConfig"/>
        <mkdir dir="build/generated/jaxbCache" xmlns:s="http://xml.netbeans.org/schema/JAXBWizConfig"/>
        <mkdir dir="${build.classes.dir}" xmlns:s="http://xml.netbeans.org/schema/JAXBWizConfig"/>
        <mkdir dir="build/generated/jaxbCache/HandleSystemBinding"/>
 
<!-- remove catalog attribut here or change refs in catalog.xml : catalog="catalog.xml" -->
        <xjc package="de.gbv.examples.handesystembinding" destdir="build/generated/jaxbCache/HandleSystemBinding">
            <classpath>
                <pathelement location="${src.dir}"/>
                <pathelement path="${jaxbwiz.xjcrun.classpath}"/>
            </classpath>
            <arg value="-xmlschema"/>
            <arg value="-verbose"/>
 
            <!-- customize this -->
            <schema file="web/A.xsd"/>
 
            <depends file="web/B.xsd"/>
            <!-- end customization -->
 
            <produces dir="build/generated/jaxbCache/HandleSystemBinding"/>
        </xjc>
 
        <copy todir="build/generated/addons/jaxb">
            <fileset dir="build/generated/jaxbCache/HandleSystemBinding"/>
        </copy>
        <javac destdir="${build.classes.dir}" srcdir="build/generated/addons/jaxb" source="${javac.source}" target="${javac.target}" xmlns:s="http://xml.netbeans.org/schema/JAXBWizConfig">
            <sourcepath location="${src.dir}"/>
            <classpath path="${jaxbwiz.gensrc.classpath}"/>
        </javac>
    </target>

Note: Later discussions on netbeans issue tracking showed that there is a simpler way by first running “refresh” on the bindings schema and then doing “clean and build”. For that you don’t need to modify the ant target, nevertheless the discussed modification gives you this with just the “Regenerate” action click.

It seems to me that there are basically two ways to get started with the examples of the Jersey distribution (see also Java Webservices – Relationship between JAX-WS, JAX-RS, Metro and Jersey) in Glassfish.

First you can use the Glassfish’s update center executing:
$path/updatecenter/bin$ ./updatetool
like described for example in Japod’s blog.
But currently only version 0.4 is available here.

The other way is : download and unzip the newest version of Jersey. In the root directory of the unzipped archive you will find an
ant script, execute it like this:
$path/jersey-0.5-ea$ ant -f jersey-on-glassfish.xml -Dgf.home=$HOME/bin/glassfish install
with appropriate gf.home property supplied.

If you get an error message similiar to this one:
BUILD FAILED
/home/kostja/Development/jersey/jersey-0.5-ea/jersey-on-glassfish.xml:103: The following error occurred while executing this line:
/home/kostja/Development/jersey/jersey-0.5-ea/jersey-on-glassfish.xml:43: /home/kostja/Development/jersey/jersey-0.5-ea/examples/GlassfishDB not found.

which means some example is missing in the distribution, edit the jersey-on-glassfish.xml file, comment out the matching lines:

     <!-- copy-example example.name="GlassfishDB"/>
     <update-nb-prop nb.prop.file="${gf.home}/jersey/examples/GlassfishDB/nbproject/project.properties"/ -->

Be aware! This procedures will only install the examples and won’t add auto-magically the jersey jars to Glassfish’s runtime classpath. So
you have to take care by yourself to include the jars to the build target, see the provided examples for the jars needed:

glassfish/jersey/examples/SimpleServlet/nbproject/build-impl.xml:

    <target depends="init" name="library-inclusion-in-archive" unless="dist.ear.dir">
        <copy file="${file.reference.activation.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jsr250-api.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.persistence-api-1.0.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.asm-3.1.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jsr311-api.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jersey.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
    </target>

glassfish/jersey/examples/SimpleServlet/nbproject/project.properties:

# some of this properties are set by jersey-on-glassfish.xml
# during installation
ashome.jersey.lib.dir=../../lib
ashome.lib.dir=../../../lib
...
file.reference.jsr250-api.jar=${ashome.jersey.lib.dir}/jsr250-api.jar
...
file.reference.jersey.jar=${ashome.jersey.lib.dir}/jersey.jar
...
javac.classpath=${file.reference.servlet.jar}\:${file.reference.activation.jar}\:${file.reference.jsr250-api.jar}\:
${file.reference.persistence-api-1.0.jar}\:${file.reference.asm-3.1.jar}\:${file.reference.jsr311-api.jar}\:
${file.reference.jersey.jar}

Have you ever wondered about the relationship of different actors within Java’s Webservice Stack? I did. The key to the right answers you may find watching this list of Glassfish projects.

So there seems to be a simple formula (RI = reference implementation):

JAX-WS = JAVA-API( XML-based Webservices, means mainly WSDL/SOAP though REST is possible too )
RI(JAX-WS) = { javax.xml.ws.**.* , core Web services support } = JAX-WS “RI” [is subset of] Metro
Metro = JAX-WS “RI” + WSIT/Tango ( WSIT/Tango provides support for Security, Reliability, Transactions and Interoperability with .NET 3.0 )

JAX-RS = JAVA-API( RESTful Web Services )
RI(JAX-RS) = { javax.ws.rs.**.* } = Jersey

JAX-WS 2.1 along with JAXB 2.1 is integrated in JDK 6 Update 4 release as is JAX-WS in JDK 6. It is part of Java EE 5 as well. To use Metro 1.1 on JDK6 U4, you just have to put the Metro jars in the classpath. Metro is integrated with Glassfish Application Server.
It is possible to run REST Services with JAX-WS using the appropriate Binding like described in RESTful Web Services.

JAX-RS is yet not finally released (see Schedule). If you are using NetBeans IDE 6.0, you do not need to download the Jersey distribution. Instead, install the RESTful Web Services plugin from the Plugin Manager under the Tools menu. Developing RESTful Webservices is much easier here. Implementing RESTful Web Services in Java provides a good start.

If you are looking for the Metro libraries, either get them from GlassFish (webservices*.jar) , or download them from Metro distribution.

Some nice slides for an Metro/Jersey overview : Metro and Jersey.

To use Metro in your application you will need this jars (see also Metro FAQ):
$METRO_HOME/lib/webservices-rt.jar
$METRO_HOME/lib/webservices-api.jar
$METRO_HOME/lib/webservices-extra-api.jar
$METRO_HOME/lib/webservices-extra.jar

It seems that we finally have got this simple feature for classpath (see Bug ID: 4339262).

Now it is possible to use wildcards in classpath definition:
javac -cp libs/* -verbose -encoding UTF-8 src/mypackage/*.java -d build/classes

This is a citation from man:java (java-6-sun, linux):

-cp classpath
Specify a list of directories, JAR archives, and ZIP archives to search for class files. Class path entries are separated by colons (:). Specifying -classpath or -cp overrides any setting of the CLASSPATH environment variable.

If -classpath and -cp are not used and CLASSPATH is not set, the user class path consists of the current directory (.).

As a special convenience, a class path element containing a basename of * is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR (a java program cannot tell the difference between the two invocations).

For example, if directory foo contains a.jar and b.JAR, then the class path element foo/* is expanded to a A.jar:b.JAR, except that the order of jar files is unspecified. All jar files in the specified directory, even hidden ones, are included in the list. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory. The CLASSPATH environment variable, where defined, will be similarly expanded. Any classpath wildcard expansion occurs before the Java virtual machine is started — no Java program will ever see unexpanded wildcards except by querying the environment. For example; by invoking System.getenv(“CLASSPATH”).

To see your currently used user directory go to Help – About – Details.

To override the default settings in the file netbeans-install-dir/etc/netbeans.conf you can create a directory etc/ in /home/myhome/.netbeans/6.0 ( with 6.0 being the version number of your NetBeans installation). Then use the default netbeans.conf file from netbeans-install-dir/etc/netbeans.conf as a template to create a user specific settings in /home/myhome/.netbeans/6.0/etc/netbeans.conf (see How do I make my custom startup parameters permanent? ).

For instance you could change you user name (used in templates):
# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-XX:PermSize=64m -J-XX:MaxPermSize=200m -J-Xverify:none -J-Duser.name='My Name' -J-Dapple.laf.useScreenMenuBar=true -J-Dswing.aatext=true --fontsize 14"

(… or use Tools -> Template Manager -> User configuration properties .)

Read more about startup parameter for Netbeans IDE in FaqStartupParameters .

Next Page »