Tag Library Project:
Requirements and Scenarios

Author: Ann Sunhachawee
Document History in CVS
Last Updated: July 24 2003
Revision: 1.1

Table of Contents

1. Introduction
2. Users
3. Requirements
4. Usage Scenarios
5. Issues
6. What can be done with Tag Library Project as a resource  in Web Module Projects
7. Future Requirements
   

1 Introduction

The Tag Library Project is primarily for the author of Tag Libraries to create a tag library that will be reused and distributed by other web modules.  This project will produce Tag Library Descriptors (TLDs) and Tag Library JAR files. The author could test their tag library by including the Outputs as Resources for the test web module projects.

The purpose of this document is to discuss the users of the tag library project, explore their requirements, and how they will use the Tag Library project within the IDE. This will give basis and input on how the design should be.

2 Users

• Author of tag libraries aimed for distribution
  
• Web module developers using tag libraries being developed concurrently
  

3 Requirements

• Ability to create and edit J2EE 1.4 Tag Libraries
  
• Ability to create and edit J2EE 1.3 Tag Libraries
  
• Ability to browse J2EE 1.3 and 1.4 Tag Libraries Descriptors (J2EE 1.2 libraries pending clarification of parent requirements)
  
• Able to work with existing tlds and sources developed outside of IDE
• Retain user's code in the tag handlers
  
• Create 1 or more TLDs per Tag Library jar
  
• Able to use Java Projects as resource dependencies
  
• Able to debug resource dependencies (e.g. Java Projects) seamlessly from TL Project
  
• Able to VCS TLDs and sources
• Upgrade J2EE 1.3 Tag Libraries to J2EE 1.4 (Upgrade of J2EE1.2 TL is pending clarification of parent requirements)
  
• Refactoring - within TL project itself and refactoring notifications can occur across projects
  
• Output ("Build Step") can be
  
• Tag Library JAR
  
• jar (pending if Java Project has support for creating extra jars)
  
• Create new classes (for auxiliary classes and unit tests), new files (tag files, tag fragments, etc)
• TLDs can be created for tag files
  
• Use common editor framework to edit Tag Library
• TLDs can be placed in the project and the sources will either be found or created (may need some user input)

3.1 Requirements of Projects Infrastructure

• Able to add sources after TL project has been created
• Ability for customize Run action - run a Web Module instead of a TL
• Ability to specify templates that show in context sensitive New, ability to customize/control what shows in the entire list of templates
• Ability to handle different types of documentation tools, e.g. Javadoc as well as TLD Doc, when it is implemented
• Refactoring notifications can occur across projects
  

3.2 Non Requirements

• Including TLDs in TL Project that are from other TL Projects
• Unit testing support
  
• Creating multiple Tag Library JARs per TL Project

4 Usage Scenarios

• Developing from Scratch
  

• Creates new Tag Library Project through New Wizard. Information that user can provide:
  
• New Project (specify proj name, directory)
  
• Continuing panes: A TLD will by default be in the project, default name is same as the project's
• Chooses 1.3/1.4 TL
• TLD Editor will appear in the editor area upon finishing wizard
• Can add and edit tag files, tag fragments
  
• Can add files meant for auxiliary jars (user must create new Build Steps to create a jar)
• To test the TL, user invokes the Run action. If not configured, the user will choose which Web Module project to run that exercises the TL.
  
• Debugging will happen seamlessly when running the Web Module project
• Create new Tags, Tag Files through the New wizard. Corresponding Tag handlers and TLDs will be created upon completion of the wizard.
  

• Developing with Existing Tag Library

• Creates new Tag Libary Project through New Wizard (have separate project Tag Library from Existing Sources?)
• Point at existing TLDs, java packages with handlers, tag files, other sources.
  
• Asked if they want to upgrade if TL is detected as < 1.4 (not sure what can be done if < 1.3)
• TLD Editor will appear in the editor area upon finishing wizard.
• User can modify the TL, add to it
  
• Same as Scenario of developing from scratch
  

• Testing (From a web module project)
  
• From a web module project, add a tag library as a resource. Place the tag library (i.e. JAR or TLD and JAR or Java package) in WEB-INF. IDE should provide defaults
• If running in debug mode, then user can step through the web module into the tag library project files, also when user has breakpoints within tag library files, these should be honored.
  
• VCS
• VCSing the entire project would include vcs'ing the project file, the sources, the TLDs.
  
• After unmounting TL project, restart IDE  running WM using TL project
• Should work just like Java projects relying on a resource that is a project.
  

5 Issues

1. What to do with < J2EE 1.3 Tag Libraries? A: Pending clarifications on parent product requirements
   
2. What will adding a resource to a  TL project mean? Adding auxiliary jar files which you don't have source to?
   
3. how common is it for user to want to create auxiliary jars? Have them built separately than the TL (currently concerned with Output only allowing one "default" build target to be built.)
   

6 What can be done with Tag Library Project as a Resource in Web module project?

• Browse TLDs
• Must allow for letting user place TL files in WM structure
• When adding TL as a resource, during add resource wizard, user sees that tld will be placed in WEB-INF/lib, though can change this through checkbox "Use recommended location". Must have some way to add jars/packages to correct place in WEB-INF
  

7 Future

• Support for TLD Doc
• As unit testing is supported by Java Project, add unit test support for TL Project
• Advanced refactoring - splitting tags, moving tags to another TLD, etc