readme

AIOTrade is a free, open source stock technical analysis platform built on pure java. Its pluggable

In a <run-dependency> you can also use just

    <implementation-version/>

in place of <specification-version>, meaning to declare an implementation
dependency on another module. The actual version is taken directly from that
module's current JAR so you do not need to keep track of it. *Important*: if you
either *export* or *import* any implementation dependencies, you should probably
use spec.version.base (see below).

Specify your test dependencies on other modules [since 5.0u2, requires /3
schema]. The tags in project.xml are 
described below:

    <test-dependencies>
        <! -- Dependencies for a source root with tests: -->
        <test-type>
            <!--
            Name of test type. Normally you will use 'unit'.
            netbeans.org modules also support 'qa-functional' test-type.
            -->
            <name>unit</name>
            <!-- A dependency on a module or its tests: -->
            <test-dependency>
                <!-- Identification of module our tests depend upon: -->
                <code-name-base>org.netbeans.modules.java.project</code-name-base>
                <!-- Include also transitive module dependencies of that module: -->
                <recursive/>
                <!-- Always available when running, but to include at compile time also: -->
                <compile-dependency/>
                <!-- To request the tests of that module as well: -->
                <test/>
            </test-dependency>
        </test-type>
    </test-dependencies>

Source root for a test type:
{project.dir}/test/${test-type.name}/src

{project.dir}/test/unit/src  - source root for unit test


For example you have three modules with code name bases A,B,C. A depends on B, B
depends on C. You want to add test dependencies to unit test type of module D:

Use case 1: Runtime dependency on module.

<test-type>
 <name>unit</name>
 <test-dependency>
    <code-name-base>A</code-name-base>
 </test-dependency> 
</testtype>

Runtime classpath is D + A. 
Compile classpath is D.

Use case 2: Runtime dependency on a module and its recursive runtime classpath.

<test-type>
 <name>unit</name>
 <test-dependency>
    <code-name-base>A</code-name-base>
    <recursive/>
 </test-dependency> 
</testtype>

Runtime classpath is A + B + C + D.
Compile classpath is D.

Use case 3: Compile and runtime dependency on a module its recursive runtime classpath.

<test-type>
 <name>unit</name>
 <test-dependency>
    <code-name-base>A</code-name-base>
    <compile-dependency/>
    <recursive/>
 </test-dependency> 
</testtype>

Runtime classpath is A + B + C + D.
Compile classpath is A + B + C + D.

Use case 4: Compile and runtime dependency on a module, its recursive runtime classpath 
and tests.

<test-type>
 <name>unit</name>
 <test-dependency>
    <code-name-base>A</code-name-base>
    <compile-dependency/>
    <recursive/>
    <test/>
 </test-dependency> 
</testtype>

Runtime classpath is A + B + C + D + A/test/unit.
Compile classpath is A + B + C + D + A/test/unit.

Declare any public API/SPI packages you export:

    <public-packages>
        <package>org.netbeans.api.foo</package>
        <package>org.netbeans.spi.foo</package>
    </public-packages>

If you do not export any API, say so:

    <public-packages/>

If you export an API to selected modules only, you can use (NB 5.0+ only!):

    <friend-packages>
        <friend>org.netbeans.modules.brother</friend>
        <package>org.netbeans.modules.foo.spi</package>
    </friend-packages>

If you bundle a special library which you want to expose to modules depending on
you, you need not enumerate every package explicitly:

    <public-packages>
        <subpackages>javax.foo</subpackages>
    </public-packages>

Exported implementation "APIs" do not need to be declared; anyone depending on
your module with an implementation dependency gets access to *all* your
packages. Be careful and avoid this situation whenever possible.

If your module bundles one or more third-party libraries, declare them:

    <class-path-extension>
        <!-- Deployed path, relative to dir containing module: -->
        <runtime-relative-path>ext/foolib.jar</runtime-relative-path>
        <!-- Path of library in your own sources, relative to project basedir: -->
        <binary-origin>external/foolib.jar</binary-origin>
    </class-path-extension>

You still need to separately copy the JAR to the output directory (see below).
This just declares that Class-Path in your module's manifest should be defined,
and adds a compile-time classpath entry for your module and modules depending on
it.

If your bundled library is built from sources, just use

    <class-path-extension>
        <runtime-relative-path>ext/foolib.jar</runtime-relative-path>
    </class-path-extension>

Sometimes a module will produce some extra JARs (in modules/ext/ for Class-Path,
in ant/nblib/, etc.), or will just need to have some extra sources for
miscellaneous purposes (e.g. custom Ant tasks). You can declare them, somewhat
similarly to how freeform projects permit compilation units to be declared; you
will still need to explicitly compile and JAR them in your build.xml. For
example, for in-IDE automatic Ant tasks you might use:

    <extra-compilation-unit>
        <!-- Root of Java packages, relative to project basedir: -->
        <package-root>antsrc</package-root>
        <!-- Compile-time classpath: -->
        <classpath>${ant.home}/lib/ant.jar:${openide.dir}/core/openide.jar</classpath>
        <!-- Places where classes are deposited: -->
        <built-to>build/antclasses</built-to>
        <built-to>${cluster}/ant/nblib/${code.name.base.dashes}.jar</built-to>
    </extra-compilation-unit>

Or for a Class-Path extension built from sources, you might use:

    <extra-compilation-unit>
        <package-root>libsrc</package-root>
        <classpath/>
        <built-to>build/libclasses</built-to>
        <built-to>${cluster}/modules/ext/foolib.jar</built-to>
    </extra-compilation-unit>

A custom Ant task (or set of tasks) you use only during your own build might
look like:

    <extra-compilation-unit>
        <package-root>antsrc</package-root>
        <classpath>${ant.home}/lib/ant.jar</classpath>
        <built-to>build/antclasses</built-to>
        <built-to>build/tasks.jar</built-to>
    </extra-compilation-unit>

Note that <classpath> may contain Ant property references, so for a complex
classpath, define it once in project.properties and use that property in
<classpath> as well as in your Ant script.

If you export some API (declared in <public-packages> or <friend-packages>) and
wish to be able to build Javadoc, just specify

    <javadoc/>

PROPERTIES WHICH MAY BE DEFINED IN YOUR project.properties
----------------------------------------------------------

If needed, these properties may also be defined in private.properties (to make
them applicable to only your own checkout of sources). Only selected properties
are listed here; others may be interpreted, but see the Ant script for details.

Unless otherwise noted, properties listed here *are* available for use in
selected fields in project.xml, *are* available for use in your build.xml
(depend on some init target to make sure), and *are not* available for use when
defining other properties in project.properties (unless you defined them in
private.properties).

basedir - you cannot define this; it is always the project directory of the
module (as in any Ant script). Available in all other properties files.

build.classes.dir - "build/classes", used to send compiled classes to.

build.compiler.debug - default "true" to include debugging info when compiling
(needed if you want to step through sources).

build.compiler.debuglevel - default "source,lines,vars" to include all debugging info.

build.compiler.deprecation - default "true" to display deprecation warnings when
compiling. If you want to disable deprecations, it is recommended you use
private.properties:

    build.compiler.deprecation=false

build.test.unit.classes.dir - "build/test/unit/classes", where unit tests are
compiled to.

buildnumber - generated timestamp for use in
OpenIDE-Module-Implementation-Version (or OpenIDE-Module-Build-Version if
OpenIDE-Module-Implementation-Version was explicitly defined in the manifest).

cluster - cluster directory your module is to be built into. For netbeans.org
modules, this is a subdirectory of nbbuild/netbeans/; the subdirectory name is
defined automatically from nbbuild/cluster.properties, with a fallback to
"extra". For suite component modules, it defaults to
"${suite.dir}/build/cluster", though you could override it if you wanted (e.g.
in platform.properties); similarly, for standalone modules, it defaults to
"${basedir}/build/cluster". Available in project.properties for netbeans.org
modules only.

code.name.base.dashes - your code name base as org-netbeans-modules-foo

code.name.base.slashes - ditto, as org/netbeans/modules/foo

cp.extra - extra JARs you have to compile module sources against. Rarely needed
any more.

extra.module.files - list of special files you build alongside your module JAR
which you want to register for update tracking and include in your NBM.
*Everything* you put into your cluster should be enumerated. Paths are relative
to the cluster directory. Example:

    extra.module.files=\
        ext/foolib.jar,\
        docs/FooAPI.zip

(You do *not* need to include: the module JAR itself; your JavaHelp JAR if you
build one; your module declaration file; any module-auto-deps.xml; an
ant/nblib/*.jar corresponding to your module; or any files in ${release.dir}.
These are all included by default.)

foo/bar.dir - absolute path of cluster directory to which the netbeans.org
module "foo/bar" is built. Only defined for netbeans.org modules, and only if
foo/bar was *already* built before yours (specify <build-dependency/>).
Available in project.properties.

harness.dir - location of the build harness (for external modules). Usually
"${netbeans.dest.dir}/harness".

is.autoload and is.eager - default false, but if true, make this module an
autoload or eager module.

javac.compilerargs [since 5.0u1] - default none; additional arguments to pass
to the Java compiler, e.g. "-Xlint:unchecked".

javac.source - default "1.4"; to use JDK 1.5 features like generics:

    javac.source=1.5

javac.target - default ${javac.source}; controls version of generated bytecode

javadoc.apichanges - optional location of an API changes list. Currently for
netbeans.org modules only.

javadoc.arch - optional location of an architecture XML description. Highly
recommended as it makes your module self-documenting.

    javadoc.arch=${basedir}/arch.xml

javadoc.overview - optional location of a Javadoc overview page. Discouraged
since it disables the default content which links to various generated documents
which you would need to manually add to your own overview.

javadoc.title - title for Javadoc build. Optional for external modules.
DEPRECATED since 5.0u1; taken from other module metadata.

javahelp.base - "${code.name.base.slashes}/docs" by default; directory