If your module uses some external library, you will probably use a wrapper module to make classes from that library available to your module at runtime.
A wrapper module is a module that contains no code; really the only significant thing about it is its manifest, which does two significant things, in addition to the standard module unique ID/version/etc.:
You can use File > New Project > NetBeans Modules > Library Wrapper Module to make a library wrapper.
So a wrapper module acts as a proxy to turn a library into a NB module. Since you can't modify the NetBeans classpath directly (DevFaqNetBeansClasspath), nor would you want to, this is the way you let your code use third-party libraries. It serves the same function that running with java -cp or setting CLASSPATH would do in a smaller Java application.
There are other options for packaging libraries described in DevFaqWhenUseWrapperModule.
If the above was confusing, read DevFaqModuleDependencies.
If you are developing the library yourself, but decide you want to keep the library project separate from any NB module project, you can do so. Just make a plain Java project for the library and build it; and also create a library wrapper module from its JAR output. Here are two ways to hook them up. The first modifies the project so that when the project is built, it copies the jar to the wrapper module. The second modifies the wrapper module so that the wrapper cleans, builds and picks up the jar.
dist.jar=../../foo-wrapper/release/modules/ext/foo.jar
Now you can just build the Java SE project and it will update the wrapper's JAR file. Also code completion on anything that compiles against the foo library should "see" sources in /src/suite/libs/foo/src (so long as the Java SE project is open).
With these changes to a wrapper module, build/clean on the wrapper, or on the module suite that contains the wrapper, also does build/clean on the project.
For this example, my-wrapper is a library wrapper module for the JAR file produced by the regular Java project called my-project. my-project and my-wrapper are in the same directory; this only affects relative path specifications and is not a general requirement. This example was created on NetBeans 5.5. If you have jars from multiple projects in a wrapper, then this example is extended by using <antsub> instead of <ant> and a FileSet in the release target's <copy> task.
Only the my-wrapper project needs modification.
<binary-origin>../my-project/dist/my-project.jar</binary-origin>
Make sure a ../src directory (relative to the JAR location) containing the corresponding sources of the library exists if you want Go to Source functionality to work.
extra.module.files=modules/ext/my-project.jar
<property name="original.project.dir" value="../my-project"/>
<property name="original.project.jar"
value="${original.project.dir}/dist/my-project.jar"/>
<target name="release">
<echo message="Building ${original.project.dir}"/>
<ant dir="${original.project.dir}"
target="jar" inheritall="false" inheritrefs="false"/>
<echo message="Done building ${original.project.dir}"/>
<copy todir="${cluster}/modules/ext"
file="${original.project.jar}"/>
</target>
<target name="clean" depends="projectized-common.clean">
<echo message="Cleaning ${original.project.dir}"/>
<ant dir="${original.project.dir}"
target="clean" inheritall="false" inheritrefs="false"/>
<echo message="Done cleaning ${original.project.dir}"/>
</target>
Some libraries come with a native counterpart. The current Library Wrapper wizard doesn't cater to this. As per the JNI section in this document, you simply need to create a lib directory under <my-wrapper>/release/modules (which gets created by the wizard), alongside the ext directory mentioned earlier in this document. This directory is where you place your native libraries.
<class-path-extension>
<runtime-relative-path>ext/extra1.jar</runtime-relative-path>
<binary-origin>release/modules/ext/extra1.jar</binary-origin>
</class-path-extension>
<class-path-extension>
<runtime-relative-path>ext/extra2.jar</runtime-relative-path>
<binary-origin>release/modules/ext/extra2.jar</binary-origin>
</class-path-extension>