XML Project Type

Todd Fast
Chris Webster
Nam Nguyen


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.


  • Provide a common grouping of related XML artifacts

  • Define XML artifact specific actions at a project level without introducing any additional API requirements on existing projects

Non Goals

  • Cross file refactoring. One potential purpose of the XML project would be to serve as the scope of refactoring. This would provide the ability to have a somewhat restricted search space in which to perform refactoring. For example, renaming of a schema element would do the following:

  • 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.



    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>

    Only xml is visible in logical view as 'Files' node.

    Context Menu

    The project node has the following contextual actions:

    • New - preferred templates should be xml schema and wsdl (any others)

    • -----

    • Build Project

    • Build and Clean Project

    • Clean Project

    • -----

    • Publish to Registry

    • Remove From Registry

    • Deploy

    • Generate Documentation

    • -----

    • Set Main Project

    • Open Required Projects

    • Close Project

    • -----

    • Rename Project

    • Move Project

    • Copy Project

    • Delete Project

    • -----

    • Find...

    • -----

    • CVS

    • -----

    • Properties

    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:

    • New - preferred templates should be xml schema and wsdl (any others)

    • -----

    • CVS

    • -----

    • Find

    • -----

    • Paste

    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).

  • Project Features

    About this Project

    XML was started in November 2009, is owned by dstrupl, and has 62 members.
    By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
    Please Confirm