vmassol 01/07/01 07:37:07 Modified: cactus/docs/framework/xdocs doc-book.xml index.xml site-book.xml todo.xml Added: cactus/docs/framework/skins/jakarta.apache.org/stylesheets roadmap2document.xsl Log: new roadmap/todo page Revision Changes Path 1.13 +1 -1 jakarta-commons/cactus/docs/framework/xdocs/doc-book.xml Index: doc-book.xml =================================================================== RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/doc-book.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- doc-book.xml 2001/07/01 09:48:09 1.12 +++ doc-book.xml 2001/07/01 14:37:06 1.13 @@ -14,7 +14,7 @@ <menu-item label="Features" source="features.xml"/> <menu-item label="Goals" source="goals.xml"/> <menu-item type="changes" label="Changes" source="changes.xml"/> - <menu-item type="todo" label="Todo" source="todo.xml"/> + <menu-item type="roadmap" label="Roadmap/Todo" source="todo.xml"/> <menu-item label="Contributors" source="contributors.xml"/> <menu-item label="Contributing" source="contributing.xml"/> <menu-item label="License" source="license.xml"/> 1.15 +10 -0 jakarta-commons/cactus/docs/framework/xdocs/index.xml Index: index.xml =================================================================== RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/index.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- index.xml 2001/07/01 09:48:09 1.14 +++ index.xml 2001/07/01 14:37:06 1.15 @@ -50,6 +50,16 @@ 01/07/2001 </td> <td> + New <link href="todo.html">Roadmap/Todo</link> page that lists + the actions that need to be performed before releasing the next + version of Cactus. Come help ! + </td> + </tr> + <tr> + <td> + 01/07/2001 + </td> + <td> New <link href="ide_vajava.html">tutorial</link> for installing Cactus inside VisualAge for Java. </td> 1.12 +1 -1 jakarta-commons/cactus/docs/framework/xdocs/site-book.xml Index: site-book.xml =================================================================== RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/site-book.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- site-book.xml 2001/07/01 09:48:09 1.11 +++ site-book.xml 2001/07/01 14:37:06 1.12 @@ -14,7 +14,7 @@ <menu-item label="Features" source="features.xml"/> <menu-item label="Goals" source="goals.xml"/> <menu-item type="changes" label="Changes" source="changes.xml"/> - <menu-item type="todo" label="Todo" source="todo.xml"/> + <menu-item type="roadmap" label="Roadmap/Todo" source="todo.xml"/> <menu-item label="Contributors" source="contributors.xml"/> <menu-item label="Contributing" source="contributing.xml"/> <menu-item label="License" source="license.xml"/> 1.28 +189 -87 jakarta-commons/cactus/docs/framework/xdocs/todo.xml Index: todo.xml =================================================================== RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/todo.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- todo.xml 2001/07/01 10:29:57 1.27 +++ todo.xml 2001/07/01 14:37:06 1.28 @@ -1,92 +1,194 @@ <?xml version="1.0"?> -<!DOCTYPE todo SYSTEM "./dtd/todo-v10.dtd"> +<roadmap title="Roadmap/Todo for Cactus"> -<todo title="Things To Do for Cactus"> + <s1 title="Introduction"> + <p> + As is stated on the Cactus <link href="goals.html">goals</link> page, the + intention is to explore as much as possible in the realm of unit testing + of server side java code ... + </p> + <p> + This brings a bad news and a good one ... The + bad one is that the TODO list is likely to keep growing or at least + have a respectable size ... The good one + is that there will be work for everyone ... :-) + </p> + <p> + If you are interested in participating, send an email on the Cactus mailing + list stating your interest and you'll be enrolled right away ... We're + always looking for help ! Don't be put off if in the "Volunteer" column + there is already a person listed. On the contrary, the more person that + participate in a given task, the better (like in pair programming, several + sets of eyes are always better than one!). However you'll need to sync. + with these others persons but this is easily done by posting to the + mailing-list. + </p> + <p> + The game has just begun ... ! + </p> + </s1> + + <version title="Version 1.2"> + + <category title="Documentation"> + <action> + Update web site documentation to explain new dependency with Log4j in + the installation tutorial. + </action> + <action> + Add a tutorial for building Cactus from the source distribution. + </action> + <action> + Add a tutorial that explains how to unit test EJBs in the current + version of Cactus. + </action> + <action> + Write a tutorial that explains how to unit test Tag libraries (only + taglets that extend TagSupport for the moment). + </action> + <action> + Write a Cactus integration tutorial for JBuilder 4/5 that explains how + to run Cactus tests within JBuilder4/5. + </action> + <action> + Add a tutorial/FAQ entry for explaining unit testing of persistent + sessions, i.e. to explain that each unit test is *independent* of + another and that each test need to set up it's own preconditions + (HTTP paramteres, cookies, HTTP headers, ...) but *also* values that + are expected to be set in the HTTP Session, application scope, ... + before running the test. + </action> + </category> + + <category title="Build Process"> + <p> + All tasks that are related to building Cactus in general. + </p> + <action assigned-to="Vincent Massol"> + Set up nightly builds (it is high time !). Almost done ! + </action> + <action> + Add support for Orion 1.5 in Ant build files (current support is for + Orion 1.4 only but may work on 1.5.2 - need to be tested though). + </action> + <action> + Add the Ant scripts for JBoss 2.x w/Tomcat provided by Jeffrey Madynski + ([EMAIL PROTECTED]) on the jakarta-commons mailing list (Subject + "[cactus] Using Cactus with JBoss-2.2.1 with Embedded Tomcat"). The + scripts need to be reworked so that the deployed test war is deployed + within the <code>out</code> output directory and not to where + JBoss/Tomcat is installed. + </action> + <action> + Add Ant scripts to support WebLogic 6.0. + </action> + </category> + + <category title="Design/Code"> + <action assigned-to="Vincent Massol, Jari Worsley"> + Continue support for JSP Taglib to fully support all types of taglets + (even the one with body content which extend TagBodySupport). At the + current time only taglib that extend TagSupport are supported. + </action> + <action> + Design and implement support for unit testing Filters (Servlet API + 2.3 only). + </action> + <action> + Handle <code>getRealPath()</code>, <code>getPathTranslated()</code> in + the <code>ServletRedirectorRequest</code> class. With the current + version if you use these API, it will return the native path for the + Servlet Redirector and not for your servlet being tested. + </action> + <action> + Add an API in <code>ServletTestRequest</code> to send data to the URL + connection output stream. This is to easily test code that sends bytes + of data as POST data to the servlet. + </action> + <action> + Check why zipped distributable files have a mode of 644 on unix systems + (it should rather be 755). Reported by Jason Crickmer. Need to verify + first that the problem still exist. + </action> + </category> + + </version> + + <version title="Version 1.x where x>2"> + + <category title="Design/Code"> + <action> + Design and implement a mechanism for supporting unit testing of EJBs. + There are several possible mechanisms : + <ul> + <li> + in-container, calling the remote methods from the testXXX() methods + by providing a helper class that looks up the home interface, create + an instance and call the method, + </li> + <li> + in-container, by providing an EJB Redirector which is itself an EJB + (and thus has access to container objects) and just call the EJB + method to test as a standard java class, providing implicit objects + to an EJBTestCase that user need to derive (exactly the same + mechanism currently used for Servlets), + </li> + </ul> + </action> + </category> + + <category title="Ideas"> + <p> + Ideas to explore ... + </p> + <action> + Create a Cactus Doclet. This will introduce new javadoc tags (like the + <link href="http://sourceforge.net/projects/ejbdoclet">EJBDoclet</link>) + that will be used by the javadoc command + to do several things : generate test classes and test methods, generate + richer documentation. Indeed, the best documentation for a method is + it's test methods that show how to use it effectively. So maybe we could + append to the HTML javadoc for a method the java test method code as an + example. + </action> + <action> + Integration to Netbeans in general and especially integration with the + Netbeans XTest module. + </action> + <action assigned-to="Vincent Massol"> + Mock Object seem to be useful (see the + <link href="mockobjects.html">comparison</link> between Cactus and + Mock objects). Now we need to think on how we could bring the benefits + of both approach together and whether it is feasible on not. + </action> + <action> + When we want to unit test classes written for the Struts framework + (for example), we can use Cactus to provide access to all Servlet API + implicit objects. However, there is still a need to get access to + Struts implicit objects (for example, calling the perform() method + of an Action class need to get hold of several Struts object + beforehand). A solution might be to provide some factory helper classes + to provide these objects. This could go in a + <code>org.apache.commons.cactus.util.struts</code> package but will + need to be maintained and synced with Struts versions. Another solution + might be to host these helper classes within Struts itself. We need to + think about that (same issue as with Ant custom tasks - There have + been lengthy discussion on the subject on the Ant mailing list). + </action> + <action assigned-to="Jari Worsley"> + Integrate with HttpUnit so that we can use DOM representations and + associated API within Cactus in order to validate returned output from + servlet output stream. Integration could be done by providing these + HttpUnit features in the endXXX() method. Need to validate how the + integration could be done (Russell Gold propose extending the HttpUnit + WebResponse class - Check thread + "[cactus]A Heath Robinson lash up with HttpUnit" in Jakarta Commons + mailing list) + </action> + + </category> - <devs> - <person name="Vincent Massol" email="[EMAIL PROTECTED]" id="VMA"/> - </devs> - - <actions priority="high"> - <action context="build"> - Set up nightly builds (it is high time !). Almost done ! - </action> - <action context="docs"> - Update web site documentation to explain new dependency with Log4j - </action> - <action context="docs"> - Write a Roadmap page to explain the planned future versions, when they - will be delivered and what will be in them ... - </action> - </actions> - - <actions priority="medium"> - <action context="docs"> - Write a tutorial that shows how to test EJBs. - </action> - <action context="samples"> - Add a sample that shows how to test EJBs. - </action> - <action context="design"> - Add support for testing custom JSP Taglibs (suggested by Sohail Aslam) + - tutorial + sample - </action> - <action context="design" assigned-to="VMA"> - Add support for testing Servlet API 2.3 Filters. - </action> - <action context="code"> - Provide support for easier testing of EJBs. The mechanism is yet to be - defined (requested by notyy and others!). - </action> - </actions> - - <actions priority="low"> - <action context="build"> - Upgrade from Orion 1.4 to Orion 1.5.2 - </action> - <action context="build"> - Add the Ant scripts for JBoss 2.x w/Tomcat provided by Jeffrey Madynski - ([EMAIL PROTECTED]) - </action> - <action context="docs"> - Write a Cactus integration tutorial for JBuilder 4. - </action> - <action context="build"> - Add Ant scripts to support WebLogic 6.0. - </action> - <action context="code"> - Handle <code>getRealPath()</code>, <code>getPathTranslated()</code> in the - <code>ServletRedirectorRequest</code> class. - </action> - <action context="code"> - Add API in <code>ServletTestRequest</code> to send data to the URL - connection output stream. This is to easily test code that sends bytes - of data as POST data to the servlet (requested by Daniel Cohen and - custommonkey). - </action> - <action context="code"> - Check why zipped distributable files have a mode of 644 on unix systems - (it should rather be 755). Thanks to Jason Crickmer. - </action> - <action context="docs"> - Add a FAQ entry for explaining unit testing of persistent sessions. - </action> - </actions> - - <actions priority="wish"> - <action context="code"> - Create a Cactus Doclet. This will introduce new javadoc tags (like the - <link href="">EJBDoclet</link>) that will be used by the javadoc command - to do several things : generate test classes and test methods, generate - richer documentation. Indeed, the best documentation for a method is - it's test methods that show how to use it effectively. So maybe we could - append to the HTML javadoc for a method the java test method code as an - example. - </action> - <action context="code"> - Integration for Netbeans by integration with the Netbeans XTest module. - </action> - </actions> + </version> -</todo> \ No newline at end of file +</roadmap> \ No newline at end of file 1.1 jakarta-commons/cactus/docs/framework/skins/jakarta.apache.org/stylesheets/roadmap2document.xsl Index: roadmap2document.xsl =================================================================== <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:import href="copyover.xsl"/> <xsl:template match="roadmap"> <document> <header> <title><xsl:value-of select="@title"/></title> </header> <body> <xsl:apply-templates/> </body> </document> </xsl:template> <xsl:template match="version"> <s1 title="{@title}"> <xsl:apply-templates/> </s1> </xsl:template> <xsl:template match="category"> <s2 title="{@title}"> <table> <tr><th width="75%">Description</th><th width="25%">Volunteers</th></tr> <xsl:apply-templates/> </table> </s2> </xsl:template> <xsl:template match="action"> <tr> <td> <xsl:apply-templates/> </td> <td> <xsl:if test="@assigned-to"> <xsl:value-of select="@assigned-to"/> </xsl:if> </td> </tr> </xsl:template> </xsl:stylesheet>