Craftsman Website

Manual


Latest Release (1.0.68)

rsh tech


Generated by:
Craftsman

Crafstman Module Capabilities

[top]

This page describes the category of capabilities supported by Craftsman that are Module Extensions.

Table of Contents

java-module

    EXCLUSIVE[1]

The base capability for any Java Module extension. This capability serves as a parent for other Java-related extensions. Its options and restrictions are inherited by its children.

options:

manifest-entry
An entry to be added to the MANIFEST.MF file when the module is packaged. This entry is the full text; that is, it includes both the entry name and the entry value. So an entry of Foo-Bar with a value of "This is the value of Foo-Bar" would be the text value of "Foo-Bar: This is the value of Foo-Bar".
  • multiple entries allowed
  • valid values:
package-exclude-library
Specifies a library to exclude from packaging. This library will be excluded from any packaging or referencing in the final packaging.
  • multiple entries allowed
  • valid values:
javadoc-package
Package to process when documenting the module via Javadoc. If this option is specified, only the values of this option will be processed (that is, the values become the only package names processed).
  • multiple entries allowed
  • valid values:
javadoc-exclude-package
Package to exclude when documenting the module via Javadoc. This will be applied to whatever inclusion pattern is in use (which is either everything in the source directory or the packages listed via the "javadoc-package" option).
  • multiple entries allowed
  • valid values:
javadoc-maxmemory
Maximum memory to use with the Javadoc tool. Default value is 128M. If Javadoc is running out of memory, use this option to increase the value.
  • valid values:

[back to top]

java-module-with-libs

    extends java-module
    EXCLUSIVE[1] by inheritance

This capability represents Java modules that react to their compiled libraries, either in terms of runtime classpath entries via the MANIFEST.MF or in terms of packaging requirements. Two such examples would be Java Applications (which can reference libs via Class-Path for executable jars) or EJB jars (which require the libraries to be specified via the MANIFEST.MF Class-Path).

options:

use-manifest-classpath
Create a Class-Path entry in the MANIFEST.MF file when this module is packaged.
  • valid values:
    • empty[3] (implies "true")
    • "true"
    • "false"
manifest-classpath-prefix
Prefix to use when creating the Class-Path entry. The default prefix is none. Creating this option means that the value is then used instead of the empty prefix. A value of "lib" would result in a Class-Path entry value of "Class-Path: lib/thing1.jar lib/thing2.jar ...".

[back to top]

java-app

    extends java-module-with-libs
    EXCLUSIVE[1] by inheritance

A Java Application (not to be confused with a J2EE Application--which requires a J2EE server). Java applications are stand-alone applications with the ability to execute via a main method. They can be packaged in such a way to make the resulting jar an executable jar (e.g. java -jar foo-1.1.0.jar).

options:

bundle-name
Name to use for the resulting bundle (where the bundle represents an executable package of the module plus its required libraries). The default value used is the "${module_id}-${module_version}.zip".
main-class
The class to use as the default for an executable jar. Needs to be the fully-qualified classname (package.Type).
  • valid values:

[back to top]

j2ee-ejb

    extends java-module-with-libs
    EXCLUSIVE[1] by inheritance

A J2EE Enterprise Java Bean module. Such modules are created to be deployed within J2EE servers. EJB jars have special requirements to make them deployable and executable across a wide range of J2EE server implementations. This capability takes care of those packaging requirements while providing options to allow the module generation or packaging to be customized or augmented.

options:

ejbdoclet
Use Xdoclet's <ejbdoclet> to create remote interfaces, home interfaces, deployment descriptors, etc for this module. This option implies generate-home, generate-remote, and generate-descriptor.
  • valid values:
target-server
The target server that a specialized deployment descriptor should be generated for (note: this must match the values used by Xdoclet). Multiple entries mean that a specialized descriptor will be generated for each target-server (allowing the resulting jar to be deployed seamlessly on any of the specified target server platforms).
  • multiple entries allowed
  • valid values:
generate-home
Generate the Home interface for the EJB. This value is implied by "ejbdoclet". If specified when "ejbdoclet" is not, only the Home interface is then generated.
  • valid values:
    • empty[3]
    • "true"
    • "false"
generate-remote
Generate the Remote interface for the EJB. This value is implied by "ejbdoclet". If specified when "ejbdoclet" is not, only the Remote interface is then generated.
  • valid values:
    • empty[3]
    • "true"
    • "false"
generate-descriptor
Generate the generic deployment descriptor (as opposed to the specialized one from target-server)for the EJB. This value is implied by "ejbdoclet". If specified when "ejbdoclet" is not, only the generic deployment descriptor is then generated.
  • valid values:
    • empty[3]
    • "true"
    • "false"
ejb-spec
Specifies what EJB specification to use when generating descriptors (default is "2.0").
  • valid values:
    • empty[3]
    • "1.1"
    • "2.0"
    • "2.1"
exclude-tag
Javadoc tag to exclude when performing Xdoclet processing.
  • multiple entries allowed
  • valid values:

[back to top]

j2ee-webapp

    extends java-module
    EXCLUSIVE[1] by inheritance

A J2EE Web Application (that is, a module that results in a WAR file). This capability allows a module to be packaged in a form that is deployable as a J2EE Web Application.

options:

app-name
The name for the web application (that is, the name of the resulting WAR file). If not specified, the name of ${module_name}-${module_version}.war is used for the WAR. Please note: this value or the resulting value implied by the WAR filename can be overriden in the EAR deployment descriptor.
  • valid values:
root
The name of the the Web root directory this module is using to store its resources and JSPs in. Default value used by Craftsman is "root". If you are using IntelliJ IDEA, your default from the Editor is "resources". If using MyEclipse, the default is WebRoot. Specify whatever directory you are using if it is not the default value of "root".
  • valid values:
web-inf
The name of the directory that represents your Web Application's WEB-INF directory. You should not need to use this value unless your IDE or module is setup in a very non-standard way. Craftsman is very good at finding your WB-INF directory, assuming it is actually named "WEB-INF" and is contained in your module directory.
  • valid values:
use-web-inf-classes
Package any Java code contained in this module not in the usual module jar but within WEB-INF/classes in the final WAR package/directory.
  • valid values:
    • "true"
    • "false"

[back to top]

java-ws-enabled

This is a "mixin" that allows you to make modules that inherit from this one Java WebServices enabled. The java-ws module is an example of this.

This capability allows a module to leverage the JWSDP to create web services or web services clients. In order to get the full capabilities, you must have craftsmans-jwsdp installed and the JWSDP installed locally per the craftsman-jwsdp module's instructions. options:

ws-enabled
Enabled WebService support. This value defaults to true if the capability (or one of its children is specified). For example, if a module is specified to be "java-ws", this value is assumed to be true. If this option is set to false, all WebService support is disabled, no matter what other option or capability is specified.
  • valid values:
    • empty[3]
    • "true"
    • "false"
jwsdp-home
The home of the JWSDP toolkit. This value overrides any JWSDP_HOME value in the environment.
  • valid values:
wscompile-config
The config file to use with the JWSDP wscompile tool. If this option is not specified, "wscompile-config.xml" is used by default. The value of this option overrides that default value.
  • valid values:
wscomppile-mode
The mode to use when calling wscompile. There are 4 modes in which wscompile can be used with this capability: wsdl2java, java2wsdl, manual-wsdl2java, manual-java2wsdl. The first two are "automatic" modes--they will cause the build to always call wscompile. The later two modes are "manual" modes--wscompile will not be called unless done so manually (using the wsgensrc target). The wsdl2java modes will take the WSDL file specified in the wscompil-config file and generate Java code for it. This code will be generated the temporary build directories. The java2wsdl file will use the settings from the wscompile-config file to create a WSDL file from the specified Java code.
  • valid values:
    • "wsdl2java"
    • "java2wsdl"
    • "manual-wsdl2java"
    • "manual-java2wsdl"
generate-mode
This is the "generation" mode to use when calling wscompile. This will determine what kind of code is generated as a result of wscompile: client stub code, server code, both client and server-code, or the "define-only" mode (see the wscompile documentation for more explanation).
  • valid values:
    • "client"
    • "server"
    • "both"
    • "define-only"
keep-source
Whether the source code generated by wscompile should be kept, or if it should be removed once the stubs, helpers, etc are created. Default value is false.
  • valid values:
    • "true"
    • "false"
ws-source-dest
Where to store the generated source code (which is different from where it is compiled to). This option allows you to keep the generated source in a separate directory, whether in the build directories, the source directories, or somewhere else entirely.
  • valid values:
infix
Specify an infix to use for generated ties and serializers.
  • valid values:
unwrap
Enable unwrapping of document/literal wrapper elements in WSI mode. Default value is false.
  • valid values:
    • "true"
    • "false"
literal-encoding
Which literal encoding mode to use: document or RPC.
  • valid values:
    • "document"
    • "rpc"
wsi-enabled
Enable WSI-Basic Profile features, to be used for document and RPC literal encoding. Defaults to false.
  • valid values:
    • "true"
    • "false"
data-binding-enabled
Enable data binding for literal encoding. Default is true.
  • valid values:
    • "true"
    • "false"
validate-wsdl
Validate the WSDL file passed in via the configuration. Defaults to true.
  • valid values:
    • "true"
    • "false"
override-existing
Regenerate classes that already exist in the classpath. Defaults to true.
  • valid values:
    • "true"
    • "false"
allow-one-way-ops
Allow generation of one-way operations. Defaults to false.
  • valid values:
    • "true"
    • "false"
data-handler-only
Always map attachments to the DataHandler type. Defaults to false.
  • valid values:
    • "true"
    • "false"
explicit-service-context
Enable explicit service context mapping. Defaults to false.
  • valid values:
    • "true"
    • "false"
use-base-enum-type
Map anonymous enumeration to its base type. Defaults to false.
  • valid values:
    • "true"
    • "false"
encode-type-information
Enable encoding type information. Defaults to true.
  • valid values:
    • "true"
    • "false"
multi-ref-support
Enable multi-ref support. Defaults to true.
  • valid values:
    • "true"
    • "false"
gen-rpc-structs
Enable generating RPC structures. Defaults to true. Setting this to false sets up wscompile to import only.
  • valid values:
    • "true"
    • "false"
resolve-id-ref
Resolve xsd:IDREF. Defaults to false.
  • valid values:
    • "true"
    • "false"
search-schema
Search schema aggressively for types. Defaults to false.
  • valid values:
    • "true"
    • "false"
serliaze-interfaces
Enable direct serialization of interface types. Defaults to false.
  • valid values:
    • "true"
    • "false"
strict-mode
Generate code strictly compliant with JAXRPC spec. Defaults to false.
  • valid values:
    • "true"
    • "false"

[back to top]

java-ws

    extends java-module-with-libs, java-ws-enabled
    EXCLUSIVE[1] by inheritance

A module that will either be a web service server or a web service client. This module is a standard Java module with library dependencies that has access to the Craftsman features for the JWSDP and wscompile. Currently, the capability has only been tested against the JBoss WebService support.

This module is intended to function like j2ee-ejb: a component that is bundled via the j2ee-app module. Deployment is based on that design (things like the webservice.xml, etc are bundled in the actual module jar, with the jar then being bundled and deployed in the EAR).

[back to top]

j2ee-app

    extends java-module
    EXCLUSIVE[1] by inheritance

A J2EE Application (that is, a module which results in an EAR file). This is a special capability, as it disables the search for a source directory (that is, ${module_dir}/src is not required for this module to build). J2EE App modules are more accurately "packaging/deployment" modules, as they contain no code or implementation--they merely refer to modules within a project via dependencies and package the modules, their libraries, and any additional libraries into a properly formatted EAR.

options:

app-name
The name for the application (that is, the name of the resulting EAR file). If not specified, the name of ${module_name}-${module_version}.ear is used for the EAR.
  • valid values:
context-root
A context-root entry to use for a specified web module. The format is "${module_id}:/yourrootval", where ${module_id} matches the module ID used in the dependency entry for the module. Specifying an option of <option name="context-root" value="myweb-module:/workshop/project"/> then results in an entry like the following being generated in the application.xml:
    <module>
        <web-uri>myweb-module.war</web-uri>
        <context-root>/workshop/project</context-root>
    </module>
  • valid values:
app-spec
The specification to use when generating the application.xml file ("1.3" is the default value used). Please check with your target server to see which spec version should be used.
  • valid values:
    • empty[3]
    • "1.3"
    • "1.4"

[back to top]

web-site

    extends craftsman-module
    EXCLUSIVE[1] by inheritance

A web site--that is, by declaring a module a web-site module, you can build web site content via the wikidoc extension. This means you can use the wiki syntax used in wikidoc to build a web site. While there may be many tools (such as Dreamweaver or Frontpage), this module as added for those who would prefer to just build sites using wiki syntax. It is actually quite handy ;-)

options:

site-name
The name for the web site (used when creating the archive for publishing). If site-title is not set, this value is used for the page titles.
  • valid values:
site-title
The title for the web site. This value will be used in the top of the pages (assuming the standard SiteTemplate.html is used).
  • valid values:
root
The directory (within the module directory) that contains other resources for creating the site. The contents of this directory will be joined with the results of the wiki pages to make the final site contents. Default value is "root".
  • valid values:
deployment-dir
The directory to deploy the website to. This is where the web site will actually "live". Only SSH is currently supported. An example value would be something like "username@somesite.com:~/www/html".
  • valid values:
deployment-file
The file to deploy the website to. This will be the filename on the remote deployment directory. For example, if the file value is "website.zip" and the deployment-dir is "username@somesite.com:~/www/html", the web site archive will be named "website.zip" when it is uploaded to "username@somesite.com:~/www/html".
  • valid values:
[back to top]
[#1] Exclusive in the sense that there can only be one instance of this capability, including any children. So if a parent is marked exclusive, both it and any of its children are considered exclusive of one another, and only one of them may be used in a module.

[#2] The "any" value represents any non-null string, non-empty string. It does not include the null value or the string "".

[#3] The "empty" value represents an empty string, that is "".

[#4] The "none" value represents a null value, which result from an option specification like <option name="foobar"/>.