XML Project Type
Authors:
Todd Fast
Chris Webster
Nam Nguyen
Background
XML artifacts such as WSDL and schema are ubiquitous; therefore,
there is currently no project type which serves as shareable
repository. This becomes increasing evident when XML artifacts
reference other XML artifacts (such as WSDL imports and XML Schema
include). The policies for resolving XML references are
potentially complex and require a UI to allow the developer to adapt
to their environment (for example, on- or off-network). In addition,
locating XML files that are referenced from multiple locations (i.e.
projects) as a single unit makes management of these artifacts and
their dependencies much easier and more consistent. Finally, there
are a number of features that could benefit from some notion of a
defined collection of XML files.
Goals
Non Goals
WSDL - see if any messages are
referencing the specified type and change the type.
Schema - see if any references
are for the type and change the reference
Instance Documents - see if any
instance document is using the element (and change the name).
Project Based Catalog File - A catalog could serve as a
reference for the entire project. This approach while valid is not
the approach taken with dependency resolution, a sparse per
artifact catalog is used instead.
Plugability for documentation task – Users who wish to
use documentation generation infrastructure other than the default
one could just override the 'documentation' target in project top
level build.xml.
Proposal
Infrastructure
A new ant based project type will be created for the XML project
type. The project will provide the appropriate lookups described in
http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-projectapi/org/netbeans/api/project/Project.html#getLookup()
. The project build script xslt as well as the project.xml schema
will need to support the appropriate features specified in this
document.
Project Wizard
The project wizard should be consistent with the other new project
wizards (the wizard should be contained under a new XML folder) and
should collect:
Project Name
Project Location (with a browse
button)
Project Folder (read only text
field which concatenates the ProjectLocation and the Project Name)
Target Server combo box for
selection of web server for publishing schema, WSDL artifacts or
schema documentation.
In addition to the standard information a checkbox to set as
Main should be provided. This ensures consistency with the other
project types such as Java projects.
Project Logical View
<Project name>
Files
<directories and files>*
Project Physical Layout
<xml project directory>
src
build
conf
context.xml
web.xml
nbproject
xml
Only xml is visible in logical view as 'Files' node.
Context Menu
The project node has the following contextual actions:
Action Details:
Build - will generate an archive containing all the xml
artifacts in the project as well as documentation, thus there will be
a dependency on the documentation ANT task. The documentation ant
task is designed to be a schema / WSDL to html documentation
generation facility (similar to Java Doc), something like the
capability described in
http://lists.w3.org/Archives/Public/xmlschema-dev/2005Oct/0034.html.
The result of the build will be a war archive file.
Deploy
- Will integrate with the server api to enable deployment of the war
file. The intention is to just provide enough information to deploy
the project (this would include creating a simple web.xml). Server
Specific information would be managed by the server plug-ins. This
capability will provide a non registry repository for XML artifacts
and documentation.
Undeploy - invoke undeploy on the
web server.
Generate Documentation – Generate
schema or WSDL documentation and launch the browser, pointing the
browser to the documentation page in the local build directory.
Publish to Registry - This will provide an action for
publishing the current set of artifacts (which will be configurable
via the project property editor) to the registry.
Remove
from Registry - remove the published information from the
registry.
Properties
- The following sections will be added in the
project customizer sheet:
XML Schema Documentation - This section
will contain the various configurable properties for the XML Schema
documentation tool.
WSDL Documentation - configurable properties
on WSDL generation.
Run - may require specifying the relative
url. I am proposing running locally from the created war file so the
actual executing can be performed locally, but the server selection
and context path may still be required in this property (see the J2EE
web application project) for deployment.
Registry - The section
will contain the properties required to deploy the project to the JES
registry.
Logical view node 'Files' will have the following contextual
actions:
ANT Tasks and Targets:
Aside from typical project targets, build file
nbproject/build-impl.xml defines the following specifictasks and
targets:
docgen – task defined from opensource project xsddoc.jar (http://xframe.sourceforge.net/xsddoc/usage-ant.html).
documentation – invokes docgen task to generate schema documentation
build – invokes documentation, copy files under src to build directory and produce war file.
deploy – invokes build and nbdeploy the war file to selected target server.
run – corresponds to 'Generate Documentation' action; invokes documentation and nbbrowse to display documentation pages.
Other Potential Capabilities
Validate Ant Task - The build script could provide an integration
of the XML Validate ant task. This task allows validation of instance
documents but will likely also provide validation of the schema files
as a side effect. This will likely require the generation of a
complete catalog file which can be used to resolve all indirections.
This catalog file could be built as part of an ant task (which
considers the internal resolution strategy we are using). The Apache
catalog needs to have all URIs resolved where our approach only
requires sparse population (i.e., population of catalog only where
schemaLocation is not sufficient).
