vmassol 01/04/13 09:14:19
Modified: cactus/docs/framework/xdocs changes.xml doc-book.xml
site-book.xml todo.xml
Added: cactus/docs/framework/xdocs goals.xml
Log:
Added a "Cactus goals" page on the web site (and local documentation) that gives
rough goals and guidelines for the future of Cactus.
Revision Changes Path
1.3 +4 -0 jakarta-commons/cactus/docs/framework/xdocs/changes.xml
Index: changes.xml
===================================================================
RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/changes.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- changes.xml 2001/04/11 13:08:10 1.2
+++ changes.xml 2001/04/13 16:14:17 1.3
@@ -9,6 +9,10 @@
</devs>
<release version="1.0b2 in CVS" date="">
+ <action dev="VMA">
+ Added a "Cactus goals" page on the web site that gives rough goals and
+ guidelines for the future of Cactus.
+ </action>
<action dev="VMA" type="update" due-to="Jeff Turner"
due-to-email="[EMAIL PROTECTED]">
Improved build process so that it nows works even if junit, stylebook, ..
jars are not in the <code>CLASSPATH</code> prior to running the build.
1.3 +1 -0 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.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- doc-book.xml 2001/04/09 12:53:43 1.2
+++ doc-book.xml 2001/04/13 16:14:18 1.3
@@ -11,6 +11,7 @@
<menu label="About">
<menu-item label="News" source="index.xml"/>
<menu-item label="Features" source="features.xml"/>
+ <menu-item label="Goals" source="goals.xml"/>
<menu-item label="Changes" source="changes.xml" type="changes"/>
<menu-item label="Todo" source="todo.xml" type="todo"/>
<menu-item label="Contributors" source="contributors.xml"/>
1.3 +1 -0 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.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- site-book.xml 2001/04/09 12:53:43 1.2
+++ site-book.xml 2001/04/13 16:14:18 1.3
@@ -11,6 +11,7 @@
<menu label="About">
<menu-item label="News" source="index.xml"/>
<menu-item label="Features" source="features.xml"/>
+ <menu-item label="Goals" source="goals.xml"/>
<menu-item label="Changes" source="changes.xml" type="changes"/>
<menu-item label="Todo" source="todo.xml" type="todo"/>
<menu-item label="Contributors" source="contributors.xml"/>
1.2 +0 -11 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.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- todo.xml 2001/04/09 11:52:32 1.1
+++ todo.xml 2001/04/13 16:14:18 1.2
@@ -32,17 +32,6 @@
</actions>
<actions priority="low">
- <action context="docs" assigned-to="VMA">
- Add a page to the web site that explains the long term goals of Cactus:
- go as far as possible for testing server-side components but explain why
- this is limited and will fail in the long term as components benefit
- more and more from services provided by the container. The solution will
- be to provide testing API/SPI in the container specifications so that
- frameworks like Cactus can be plugged into the containers. Explain that
- one goal of Cactus is to make Tomcat/Sun aware of this and try to push
- in this direction. (Note: This is my view, verify if other share it or if
- I'm wrong in thinking in these terms).
- </action>
<action context="code" assigned-to="PAS">
Modify the Ant <code>runservertest</code> task so that it also works when
a servlet engine is already up and running (thanks to Philip Aston who
1.1 jakarta-commons/cactus/docs/framework/xdocs/goals.xml
Index: goals.xml
===================================================================
<?xml version="1.0"?>
<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">
<document>
<header>
<title>Cactus goals</title>
<authors>
<person name="Vincent Massol" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Short terms goals">
<p>
The short term goals for Cactus are :
</p>
<ul>
<li>
Provide a comprehensive and easy to use unit testing framework for
testing java code that uses Servlet API java classes. This includes
<ul>
<li>
Servlets,
</li>
<li>
Java code called by servlets,
</li>
<li>
Servlet 2.3 Filters,
</li>
</ul>
</li>
<li>
Try to provide mechanisms to unit test JSP taglibs. Note that this
feature is still in it's design phase. We are not sure if it is
possible nor if it is relevant for a unit test framework (it might
belong more to a functional test framework like HttpUnit).
</li>
<li>
Provide a comprehensive and easy to use unit testing framework for
testing EJB code. Note that unit testing of EJB methods that do not
use any of the container's services is already possible. The next
step is to be able to unit test the methods that calls some
container's services (like JNDI, Security, Transactions, ...).
</li>
</ul>
</s1>
<s1 title="Long term goals">
<s2 title="The Future of Unit Testing Components">
<p>
We believe unit testing server side components is going to get harder
and harder in the future. Even now, depending on the specifications
for a given component model it is more or less easy. Sometimes it is
even not feasible to test every case.
</p>
<p>
We believe that we will see more and more components in the future.
By components we mean pieces of code that execute in a container.
The container will provide more and more services for the components
(like transactions, security, life cycle, persistence, interfaces
- like web services -, logging, ...). Thus it will become harder and
harder to write a unit test framework for these components.
</p>
<p>
We believe the only satisfactory solution is to include (unit) testing
APIs as <em>part</em> of the container specifications. This could be
in the form of a SPI (Service Provider Interface) against which a
generic unit testing framework could be plugged.
</p>
</s2>
<s2 title="Long term goals for Cactus">
<p>
Expanding from the previous chapter on the future of component unit
testing, here are the future guidelines and directions that we'd like
to set for Cactus :
</p>
<ul>
<li>
Try to support all existing and forthcoming server side components
models as much as possible,
</li>
<li>
Help specify needed container API/SPI for unit testing, i.e. create
an additional service of the container : a "unit-testing service"
(in addition to the existing Security, Transaction, Life Cycle, ...
Services). As Cactus and Tomcat projects are both hosted on Jakarta
it might be a good test ground for this kind of work. Of course,
the first step would be to convince Tomcat developers that unit
testing (and testing in general) is indeed a need. The ultimate
goal will be reached when this new API/SPI is accepted and become
a de jure
standard. It would then be time to think about integrating it into
the Servlet Specifications (or other components -like EJBs -
specifications).
</li>
</ul>
</s2>
</s1>
<s1 title="Feedback needed !">
<p>
Cactus is an open source project where everyone is free to participate
(and even encouraged). Thus, we'd really like to have your opinions on
the subject of Cactus future.
</p>
<p>
How do you view the future of Cactus ?
</p>
<p>
Do you like the goals defined above ?
</p>
<p>
Do you think it is feasible ?
</p>
<p>
Please send all answers to the
<link href="mailto:[EMAIL PROTECTED]">jakarta-commons
</link> mailing list (You can subscribe by clicking
<link href="mailto:[EMAIL PROTECTED]">here
</link>). Please prefix the subject of all messages with "[cactus]".
</p>
<p>
Thanks.
</p>
</s1>
</body>
</document>
