pier 2003/03/08 15:03:07
Modified: src/documentation/xdocs Tag: cocoon_2_0_3_branch book.xml
bylaws-addendum.xml contrib.xml
src/documentation/xdocs/drafts Tag: cocoon_2_0_3_branch
cocoon2-docbook.xml
src/documentation/xdocs/faq Tag: cocoon_2_0_3_branch
faq-sitemap.xml
src/documentation/xdocs/howto Tag: cocoon_2_0_3_branch
howto-author-core-docs.xml howto-author-faq.xml
howto-author-howto.xml howto-author-snippet.xml
howto-flow-debugger.xml howto-patch.xml
src/documentation/xdocs/installing Tag: cocoon_2_0_3_branch
index.xml
src/documentation/xdocs/userdocs/concepts Tag:
cocoon_2_0_3_branch index.xml sitemap.xml
validation.xml
src/documentation/xdocs/userdocs/serializers Tag:
cocoon_2_0_3_branch xls-serializer.xml
src/scratchpad/schecoon Tag: cocoon_2_0_3_branch prj.el
src/scratchpad/webapp/mount/editor Tag: cocoon_2_0_3_branch
README
Log:
Documentation update step two. Whatever is in cocoon_2_0_3_branch of "xml-cocoon2"
should
refer to "cocoon-2.0" as its CVS repository.
Revision Changes Path
No revision
No revision
1.8.2.8 +2 -2 xml-cocoon2/src/documentation/xdocs/book.xml
Index: book.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/book.xml,v
retrieving revision 1.8.2.7
retrieving revision 1.8.2.8
diff -u -r1.8.2.7 -r1.8.2.8
--- book.xml 1 Dec 2002 03:24:14 -0000 1.8.2.7
+++ book.xml 8 Mar 2003 23:03:04 -0000 1.8.2.8
@@ -44,8 +44,8 @@
<menu label="Project">
<external label="Bug Database"
href="http://nagoya.apache.org/bugzilla/index.html"/>
- <external label="Code Repository"
href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/"/>
- <external label="Dev Snapshots"
href="http://xml.apache.org/from-cvs/xml-cocoon2/"/>
+ <external label="Code Repository"
href="http://cvs.apache.org/viewcvs.cgi/cocoon-2.0/"/>
+ <external label="Dev Snapshots"
href="http://xml.apache.org/from-cvs/cocoon-2.0/"/>
</menu>
<menu label="Links">
1.1.2.2 +10 -26 xml-cocoon2/src/documentation/xdocs/bylaws-addendum.xml
Index: bylaws-addendum.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/bylaws-addendum.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- bylaws-addendum.xml 18 Oct 2002 18:17:51 -0000 1.1.2.1
+++ bylaws-addendum.xml 8 Mar 2003 23:03:04 -0000 1.1.2.2
@@ -28,7 +28,7 @@
<ul>
<li>[EMAIL PROTECTED] mailing list</li>
<li>bugzilla</li>
- <li>xml-cocoon CVS access</li>
+ <li>cocoon-.* modules CVS access</li>
</ul>
</s3>
<s3 title="Reference mailing list">
@@ -36,35 +36,19 @@
</s3>
</s2>
- <s2 title="Community: cocoon-apps">
- <s3 title="Goal">
- <p>Create, organize and maintain applications based on
Cocoon.</p>
- </s3>
- <s3 title="Specific Resources">
- <ul>
- <li>xml-cocoon-apps CVS access</li>
- <li>bugzilla</li>
- </ul>
- </s3>
- <s3 title="Reference mailing list">
- <p>[EMAIL PROTECTED]</p>
- </s3>
- </s2>
-
</s1>
<s1 title="Repositories">
<p>The Xml.Apache Cocoon Sub-project has the following CVS
repositories.</p>
- <s2 title="xml-cocoon2">
- <p>The repository containing the Cocoon program source
code.</p>
+ <s2 title="cocoon-2.0">
+ <p>The repository containing the Cocoon 2.0.x program
source code.</p>
</s2>
- <s2 title="xml-cocoon-apps">
- <p>The repository containing the applications managed
by the
- cocoon-apps child comminuty.</p>
- </s2>
-
- <note>xml-cocoon is the 1.x branch repository, kept only for
history</note>
- </s1>
+ <s2 title="cocoon-2.1">
+ <p>The repository containing the Cocoon 2.1.x program
source code.</p>
+ </s2>
+
+ <note>cocoon-1 the 1.x branch repository, kept only for
history</note>
+ </s1>
</body>
-</document>
\ No newline at end of file
+</document>
1.6.2.4 +8 -21 xml-cocoon2/src/documentation/xdocs/contrib.xml
Index: contrib.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/contrib.xml,v
retrieving revision 1.6.2.3
retrieving revision 1.6.2.4
diff -u -r1.6.2.3 -r1.6.2.4
--- contrib.xml 7 Jul 2002 06:49:49 -0000 1.6.2.3
+++ contrib.xml 8 Mar 2003 23:03:04 -0000 1.6.2.4
@@ -34,10 +34,10 @@
</p>
<p>You can get your local working copy of the
- <link href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/";>latest and
- greatest code</link> (which you find in the xml-cocoon2 module in
+ <link href="http://cvs.apache.org/viewcvs.cgi/cocoon-2.0/";>latest and
+ greatest code</link> (which you find in the cocoon-2.0 module in
the cvs.apache.org CVS code repository, or from the
- <link href="http://xml.apache.org/from-cvs/xml-cocoon2/";>CVS snapshots</link>).
+ <link href="http://xml.apache.org/from-cvs/cocoon-2.0/";>CVS snapshots</link>).
Review the <link href="todo.html">todo</link> list, choose a task
(or perhaps you have noticed something that needs patching). Make the
changes, do the testing, generate a patch, if you need then discuss it on
@@ -213,16 +213,16 @@
<p>
This will checkout the current copy of the master cvs repository and
download it to your local disk. It will create a sub-directory called
- <code>xml-cocoon2</code>
+ <code>cocoon-2.0</code>
</p>
<ol>
<li><code>cd /usr/local/cvs</code></li>
<li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login</code></li>
<li>... use this password: <code>anoncvs</code></li>
- <li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout
xml-cocoon2</code></li>
+ <li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout
cocoon-2.0</code></li>
<li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic logout</code></li>
- <li><code>cd xml-cocoon2</code></li>
+ <li><code>cd cocoon-2.0</code></li>
</ol>
<p>
@@ -248,7 +248,7 @@
<ol>
<li><code>cd /usr/local/cvs</code></li>
<li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login</code></li>
- <li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic update -d -P
xml-cocoon2</code></li>
+ <li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic update -d -P
cocoon-2.0</code></li>
<li><strong>... pay attention to the update messages</strong></li>
<li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic logout</code></li>
</ol>
@@ -274,26 +274,13 @@
<ol>
<li>Make the desired changes in your local repository, build, test it
thoroughly</li>
- <li><code>cd /usr/local/cvs/xml-cocoon2/xdocs</code></li>
+ <li><code>cd /usr/local/cvs/cocoon-2.0/xdocs</code></li>
<li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login</code></li>
<li><code>cvs diff -u contrib.xml > $WORK/cocoon/contrib.xml.diff</code></li>
<li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic logout</code></li>
</ol>
</s2>
- <s2 title="How to get other CVS branches">
- <p>OK that got the HEAD branch of CVS into your local working copy.
- If you want some other branch, then find the relevant branch name
- from ViewCVS
- <link
href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/";>http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/</link>
(see the Tags list at the bottom).
- Then follow the same checkout procedure described above, using this ...
- </p>
-
- <ul>
- <li><code>cd /usr/local/cvs/cocoon_some_branch</code></li>
- <li><code>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout -r
cocoon_2_0_3_branch xml-cocoon2</code></li>
- </ul>
- </s2>
</s1>
<anchor id="ssh"/>
No revision
No revision
1.1.2.1 +499 -519 xml-cocoon2/src/documentation/xdocs/drafts/cocoon2-docbook.xml
Index: cocoon2-docbook.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/drafts/cocoon2-docbook.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- cocoon2-docbook.xml 3 Jan 2002 12:31:03 -0000 1.1
+++ cocoon2-docbook.xml 8 Mar 2003 23:03:05 -0000 1.1.2.1
@@ -1,525 +1,505 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
+<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"; []>
<!--
-<!DOCTYPE article
- PUBLIC "-//Norman Walsh//DTD Simplified DocBook XML V4.0.1//EN"
- "http://nwalsh.com/docbook/simple/4.0.1/sdocbook.dtd";>
+<!DOCTYPE article
+ PUBLIC "-//Norman Walsh//DTD Simplified DocBook XML V4.0.1//EN"
+ "http://nwalsh.com/docbook/simple/4.0.1/sdocbook.dtd";>
-->
-
-<book>
-<bookinfo>
- <title>Cocoon 2</title>
- <authorgroup>
- <author>
- <firstname>Stefano</firstname>
- <surname>Mazzocchi</surname>
- <affiliation>
- <orgname>The Apache Group</orgname>
- <address>
- <email>[EMAIL PROTECTED]</email>
- <otheraddr>http://xml.apache.org</otheraddr>
- </address>
- </affiliation>
- </author>
- </authorgroup>
- <abstract>
- <title>The Apache XML Project</title>
- <para>
- This document describes the Cocoon project, and its role within the
- Apache Group's Java XML project.
- </para>
- </abstract>
- <revhistory>
- <revision>
- <revnumber>0.01</revnumber>
- <date>28 May 2000</date>
- <revremark>DocBook markup</revremark>
- </revision>
- </revhistory>
-</bookinfo>
-
-<chapter>
- <title>The Cocoon Project</title>
-
-<sect1>
- <title>A new look</title>
- <para>
- The Cocoon Project will evidence its new course with a new logo that was
- designed by Cocoon's creator Stefano Mazzocchi. Here it is:
- </para>
- <figure>
- <title>The new Cocoon Logo</title>
- <graphic fileref="cocoon2.gif"></graphic>
- </figure>
-</sect1>
-
-<sect1>
- <title>Introduction</title>
- <para>
- The Cocoon Project has gone a long way since it's creation on January 1999.
- It started as a simple servlet for static XSL styling and became more and
- more powerful as new features were added. Unfortunately, design decisions
- made early in the project influenced its evolution. Today, some of those
- constraints that shaped the project were modified as XML standards have
- evolved and solidified. For this reason, those design decisions need to be
- reconsidered under this new light.
- </para>
- <para>
- While Cocoon started as a small step in the direction of a new web
- publishing idea based on better design patterns and reviewed estimations of
- management issues, the technology used was not mature enough for tools to
- emerge. Today, most web engineers consider XML as the key for an improved
- web model and web site managers see XML as a way to reduce costs and ease
- production.
- </para>
- <para>
- In an era where services rather than software will be key for economical
- success, a better and less expensive model for web publishing will be a
- winner, especially if based on open standards.
- </para>
-</sect1>
-
-<sect1>
- <title>Passive APIs vs. Active APIs</title>
- <para>
- Web serving environments must be fast and scalable to be useful. Cocoon1
- was born as a "proof of concept" rather than a production
- software and had significant design restrictions based mainly on the
- availability of freely redistributable tools. Other issues were lack of
- detailed knowledge on the APIs available as well as underestimation of the
- project success, being created as a way to learn XSL rather than a full
- publishing system capable of taking care of all XML web publishing
- needs.
- </para>
-
- <para>
- For the above reasons, Cocoon1 was based on the DOM level 1 API which is a
- <emphasis>passive</emphasis> API and was intended mainly for client side
- operation. This is mainly due to the fact that most DOM implementations
- require the document to reside in memory. While this is practical for small
- documents and thus good for the "proof of concept" stage, it is
- now considered a main design constraint for Cocoon scalability.
- </para>
-
- <para>
- Since the goal of Cocoon2 is the ability to process simultaneously multiple
- 100Mb documents in JVM with a few Mbs of heap size, careful memory use and
- tuning of internal components is a key issue. To reach this goal, an
- improved API model was needed. This is now identified in the SAX API which
- is, unlike DOM, event based (so <emphasis>active</emphasis>, in the sense
- that its design is based the <emphasis>inversion of control</emphasis>
- principle).
- </para>
-
- <para>
- The event model allows document producers to trigger producing events that
- get handled in the various processing stages and get finally formatted in
- the response stream. This has significant impacts on performance and memory
- needs:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- incremental operation
- </para>
- <para>
- the response is created during document production. Client's perceived
- performance is dramatically improved since clients can start receiving
- data as soon as it is created, not after all processing stages have
- been performed. In those cases where incremental operation is not
- possible (for example, element sorting), internal buffers store the
- events until the operation can be performed. However, even in these
- cases performance can be increased with the use of tuned memory
- structures.
- </para>
- </listitem>
- <listitem>
- <para>
- lowered memory consumption
- </para>
- <para>
- since most of the server processing required in Cocoon is incremental,
- an incremental model allows XML production events to be transformed
- directly into output events and character written on streams, thus
- avoiding the need to store them in memory.
- </para>
- </listitem>
- <listitem>
- <para>
- easier scalability
- </para>
- <para>
- reduce memory needs allow more concurrent operation to be possible,
- thus allowing the publishing system to scale as the load increases.
- </para>
- </listitem>
- <listitem>
- <para>
- more optimizable code model
- </para>
- <para>
- modern virtual machines are based on the idea of <emphasis>hot
- spots</emphasis>, code fragments that are used often and, if optimized,
- increase the process execution by far. This new event model allows
- easier detection of hot spots since it's a method driven operation,
- rather than a memory driven one. Hot methods can be identified earlier
- and their optimization performed better.
- </para>
- </listitem>
- <listitem>
- <para>
- reduced garbage collection
- </para>
- <para>
- even the most advanced and lightweight DOM implementation require at
- least three to five times (and sometimes much more than this) more
- memory than original document size. This does not only reduce the
- scalability of the operation, but also impact overall performance by
- increasing the number of memory garbage that must be collected after
- the response in sent to the client. Even if modern virtual machines
- reduced the overhead of garbage collection, less garbage will always
- have performance and scalability impacts.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The above points, alone, would be enough for the Cocoon2 paradigm shift,
- even if this event based model impacts not only the general architecture of
- the publishing system but also its internal processing components such as
- XSLT processing and PDF formatting. These components will require
- substantial work and maybe design reconsideration to be able to follow a
- pure event-based model. The Cocoon Project will work closely with the other
- component projects to be able to influence their operation in this
- direction.
- </para>
-</sect1>
-
-<sect1>
-<title>Reactors Reconsidered</title>
- <para>
- Another design choice that should be revised is the reactor pattern that
- was introduced to allow components to be connected in more flexible way. In
- fact, opposed to the fixed pipe model used up to Cocoon 1.3.1, the reactor
- approach allows components to be dynamically connected, depending on
- reaction instructions introduced inside the documents.
- </para>
-
- <para>
- While this at first seemed a very advanced and highly appealing model, it
- turned out to be a very dangerous approach. The first concern is mainly
- technical: porting the reactor pattern under an event-based model requires
- limitations and tradeoffs since the generated events must be cached until a
- reaction instruction is encountered.
- </para>
-
- <para>
- But even if the technical difficulties are solved, a key limitation
- remains: there is no single point of management.
- </para>
-</sect1>
-
-<sect1>
-<title>Management Considerations</title>
- <para>
- The web was created to reduce information management costs by distributing
- them back on information owners. While this model is great for user
- communities (scientists, students, employees, or people in general) each of
- them managing small amount of personal information, it becomes impractical
- for highly centralized information systems where <emphasis>distributed
- management</emphasis> is simply not practical.
- </para>
-
- <para>
- While in the HTML web model the page format and URL names where the only
- necessary contracts between individuals to create a world wide web, in more
- structured information systems the number of contracts increases by a
- significant factor due to the need of coherence between the hosted
- information: common style, common design issues, common languages, server
- side logic integration, data validation, etc...
- </para>
-
- <para>
- It is only under this light that XML and its web model reveal their power:
- the HTML web model had too little contracts to be able to develop a
- structured and more coherent distributed information system, reason that is
- mainly imposed by the lack of good and algorithmically certain information
- indexing and knowledge seeking. Lacks that tend to degrade the quality of
- the truly distributed web in favor of more structured web sites (that based
- their improved site structure on internal contracts).
- </para>
-
- <para>
- The simplification and engineering of web site management is considered one
- of the most important Cocoon2 goals. This is done mainly by technologically
- imposing a reduced number of contracts and place them in a hierarchical
- shape suitable to replace current high-structure web site management
- models.
- </para>
-
- <para>
- The model that Cocoon2 adopts is the "pyramid model of web
- contracts" which is outlined in the picture below
- </para>
-
- <figure>
- <title>The Cocoon2 Pyramid Model of Contracts</title>
- <graphic fileref="pyramid-model.gif"></graphic>
- </figure>
-
- <para>
- and is composed by four different working contexts (the rectangles)
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- Management
- </para>
- <para>
- the people that decide what the site should contain, how it should
- behave and how it should appear
- </para>
- </listitem>
- <listitem>
- <para>
- Content
- </para>
- <para>
- the people responsible to write, own and manage the site content. This
- context may contain several sub-contexts one for each language used to
- express page content.
- </para>
- </listitem>
- <listitem>
- <para>
- Logic
- </para>
- <para>
- the people responsible for integration with dynamic content generation
- technologies and database systems.
- </para>
- </listitem>
- <listitem>
- <para>
- Style
- </para>
- <para>
- the people responsible for information presentation, look & feel,
- site graphics and its maintenance.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- and five contracts (the lines)
- <simplelist>
- <member>management - content</member>
- <member>management - logic</member>
- <member>management - style</member>
- <member>content - logic</member>
- <member>content - style</member>
- </simplelist>
- </para>
-
- <para>
- note that there is no <emphasis>logic - style</emphasis> contract. Cocoon2
- aims to provide both software and guidelines to allow you to remove such
- contract.
- </para>
-</sect1>
-
-<sect1>
-<title>Overlapping contexts and Chain Mapping</title>
- <para>
- The above model can be applied only if the different contexts never
- overlap, otherwise there is no chance of having a single management point.
- For example, if the W3C-recommended method to link stylesheets to XML
- documents is used, the content and style contexts overlap and it's
- impossible to change the styling behavior of the document without changing
- it. The same is true for the processing instructions used by the Cocoon1
- reactor to drive the page processing: each stage concur to determine the
- result thus increasing management and debug complexity. Another overlapping
- in context contracts is the need for URL-encoded parameters to drive the
- page output. These overlaps break the pyramid model and increase the
- management costs.
- </para>
-
- <para>
- In Cocoon2, the reactor pattern will be abandoned in favor of a pipeline
- mapping technique. This is based on the fact that the number of different
- contracts is limited even for big sites and grows with a rate that is
- normally much less than its size.
- </para>
-
- <para>
- Also, for performance reasons, Cocoon2 will try to compile everything that
- is possibly compilable (pages/XSP into producers, stylesheets into
- processors, etc...) so, in this new model, the <emphasis>processing
- chain</emphasis> that generates the page contains (in a direct executable
- form) all the information/logic that handles the requested resource to
- generate its response.
- </para>
-
- <para>
- This means that instead of using even-driven request-time DTD
- interpretation (done in all Cocoon1 processors), these will be either
- compiled into processors directly (XSLT stylesheet compilation) or compiled
- into producers using logicsheets and XSP which will remove totally the need
- for request-time interpretation solutions like DCP that will be removed.
- </para>
-
- <note>
- <para>
- Some of these features are already present in latest Cocoon 1.x releases
- but the Cocoon2 architecture will make them central to its new core
- </para>
- </note>
-</sect1>
-
-<sect1>
-<title>Sitemap</title>
- <para>
- In Cocoon2 terminology, a <emphasis>sitemap</emphasis> is the collection of
- pipeline matching informations that allow the Cocoon engine to associate
- the requested URI to the proper response-producing pipeline.
- </para>
-
- <para>
- The sitemap physically represents the central repository for web site
- administration, where the URI space and its handling is maintained. An
- example of the sitemap is given below:
- </para>
-
-<programlisting>
-<![CDATA[
-<source>
- <sitemap>
- <process match="/press/en/*.html">
- <generator type="file" src="/docs/english/press/*.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/simple-press-html.xsl"/>
- </filter>
- <serializer type="html"/>
- </process>
-
- <process match="/press/en/*.pdf">
- <generator type="file" src="/docs/english/press/*.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/simple-press-pdf.xsl"/>
- </filter>
- <serializer type="pdf"/>
- </process>
-
- <process match="/">
- <matcher type="agent">
- <parameter name="name" value="Mozilla/5.0">
- </matcher>
- <generator type="file" src="/docs/root.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/fancy-XUL-view.xsl"/>
- </filter>
- <serializer type="html"/>
- </process>
-
- <process match="/">
- <matcher type="agent">
- <parameter name="capability" value="text/vnd.wap.wml">
- </matcher>
- <generator type="file" src="/docs/root.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/WAP-view.xsl"/>
- </filter>
- <serializer type="wap"/>
- </process>
-
- <process match="/">
- <generator type="file" src="/docs/root.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/normal-view.xsl"/>
- </filter>
- <serializer type="html"/>
- </process>
- </sitemap>
-</source>
-]]>
-</programlisting>
-
- <note>
- <para>
- The sitemap DTD has not yet been standardized and it's not guaranteed to
- solidify until Cocoon 2.0 is out final. So, the above should be
- considered just as a preview and not a specification or even a working
- draft. For more information dig into the development mail list digests.
- </para>
- </note>
-</sect1>
-
-<sect1>
-<title>Pre-compilation, Pre-generation and Caching</title>
- <para>
- The cache system in Cocoon1 will be ported with no important design changes
- since it's very flexible and was not polluted by early design constraints
- since it appeared in later versions. The issue regards static file caching
- that, no matter what, will always be slower than direct web server caching.
- </para>
-
- <para>
- To be able to put most of the static part job back on the web server (where
- it belongs), Cocoon2 will greatly improve it's command line operation,
- allowing the creation of <emphasis>site makefiles</emphasis> that will
- automatically scan the web site and the source documents and will provide a
- way to <emphasis>regenerate</emphasis> the static part of a web site
- (images and tables included!) based on the same XML model used in the
- dynamic operation version.
- </para>
-
- <para>
- Cocoon2 will, in fact, be the integration between Cocoon1 and Stylebook.
- </para>
-
- <para>
- It will be up to the web server administrator to use static regeneration
- capabilities on a time basis, manually or triggered by some particular
- event (database update signal) since Cocoon2 will only provide servlet and
- command line capabilities. The nice integration is based on the fact that
- there will be no behavioral difference if the files are dynamically
- generated in Cocoon2 via the servlet operation and cached internally or
- pre-generated and served directly by the web server, as long as URI
- contracts are kept the same by the system administrator (via URL-rewriting
- or aliasing)
- </para>
-
- <para>
- Also, it will be possible to avoid on-fly page and stylesheet compilation
- (which make debugging harder) with command line pre-compilation hooks that
- will work like normal compilers from a developer's point of view.
- </para>
-</sect1>
-
-<sect1>
-<title>Development Status</title>
- <para>
- Cocoon2 development already started, but should be considered of pre-alpha
- quality. If you dare, you might take a look at it on the
- <emphasis>xml-cocoon2</emphasis> CVS branch in the Cocoon CVS module, or,
- if you are not a CVS expert, this means typing:
- </para>
-
- <para>
- <command>
- cvs checkout -r xml-cocoon2 xml-cocoon
- </command>
- </para>
-
- <para>
- For more information on CVS access, refer to the CVS-howtos on this web
- site.
- </para>
-</sect1>
-</chapter>
-</book>
+
+<book>
+<bookinfo>
+ <title>Cocoon 2</title>
+ <authorgroup>
+ <author>
+ <firstname>Stefano</firstname>
+ <surname>Mazzocchi</surname>
+ <affiliation>
+ <orgname>The Apache Group</orgname>
+ <address>
+ <email>[EMAIL PROTECTED]</email>
+ <otheraddr>http://xml.apache.org</otheraddr>
+ </address>
+ </affiliation>
+ </author>
+ </authorgroup>
+ <abstract>
+ <title>The Apache XML Project</title>
+ <para>
+ This document describes the Cocoon project, and its role within the
+ Apache Group's Java XML project.
+ </para>
+ </abstract>
+ <revhistory>
+ <revision>
+ <revnumber>0.01</revnumber>
+ <date>28 May 2000</date>
+ <revremark>DocBook markup</revremark>
+ </revision>
+ </revhistory>
+</bookinfo>
+
+<chapter>
+ <title>The Cocoon Project</title>
+
+<sect1>
+ <title>A new look</title>
+ <para>
+ The Cocoon Project will evidence its new course with a new logo that was
+ designed by Cocoon's creator Stefano Mazzocchi. Here it is:
+ </para>
+ <figure>
+ <title>The new Cocoon Logo</title>
+ <graphic fileref="cocoon2.gif"></graphic>
+ </figure>
+</sect1>
+
+<sect1>
+ <title>Introduction</title>
+ <para>
+ The Cocoon Project has gone a long way since it's creation on January 1999.
+ It started as a simple servlet for static XSL styling and became more and
+ more powerful as new features were added. Unfortunately, design decisions
+ made early in the project influenced its evolution. Today, some of those
+ constraints that shaped the project were modified as XML standards have
+ evolved and solidified. For this reason, those design decisions need to be
+ reconsidered under this new light.
+ </para>
+ <para>
+ While Cocoon started as a small step in the direction of a new web
+ publishing idea based on better design patterns and reviewed estimations of
+ management issues, the technology used was not mature enough for tools to
+ emerge. Today, most web engineers consider XML as the key for an improved
+ web model and web site managers see XML as a way to reduce costs and ease
+ production.
+ </para>
+ <para>
+ In an era where services rather than software will be key for economical
+ success, a better and less expensive model for web publishing will be a
+ winner, especially if based on open standards.
+ </para>
+</sect1>
+
+<sect1>
+ <title>Passive APIs vs. Active APIs</title>
+ <para>
+ Web serving environments must be fast and scalable to be useful. Cocoon1
+ was born as a "proof of concept" rather than a production
+ software and had significant design restrictions based mainly on the
+ availability of freely redistributable tools. Other issues were lack of
+ detailed knowledge on the APIs available as well as underestimation of the
+ project success, being created as a way to learn XSL rather than a full
+ publishing system capable of taking care of all XML web publishing
+ needs.
+ </para>
+
+ <para>
+ For the above reasons, Cocoon1 was based on the DOM level 1 API which is a
+ <emphasis>passive</emphasis> API and was intended mainly for client side
+ operation. This is mainly due to the fact that most DOM implementations
+ require the document to reside in memory. While this is practical for small
+ documents and thus good for the "proof of concept" stage, it is
+ now considered a main design constraint for Cocoon scalability.
+ </para>
+
+ <para>
+ Since the goal of Cocoon2 is the ability to process simultaneously multiple
+ 100Mb documents in JVM with a few Mbs of heap size, careful memory use and
+ tuning of internal components is a key issue. To reach this goal, an
+ improved API model was needed. This is now identified in the SAX API which
+ is, unlike DOM, event based (so <emphasis>active</emphasis>, in the sense
+ that its design is based the <emphasis>inversion of control</emphasis>
+ principle).
+ </para>
+
+ <para>
+ The event model allows document producers to trigger producing events that
+ get handled in the various processing stages and get finally formatted in
+ the response stream. This has significant impacts on performance and memory
+ needs:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ incremental operation
+ </para>
+ <para>
+ the response is created during document production. Client's perceived
+ performance is dramatically improved since clients can start receiving
+ data as soon as it is created, not after all processing stages have
+ been performed. In those cases where incremental operation is not
+ possible (for example, element sorting), internal buffers store the
+ events until the operation can be performed. However, even in these
+ cases performance can be increased with the use of tuned memory
+ structures.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ lowered memory consumption
+ </para>
+ <para>
+ since most of the server processing required in Cocoon is incremental,
+ an incremental model allows XML production events to be transformed
+ directly into output events and character written on streams, thus
+ avoiding the need to store them in memory.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ easier scalability
+ </para>
+ <para>
+ reduce memory needs allow more concurrent operation to be possible,
+ thus allowing the publishing system to scale as the load increases.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ more optimizable code model
+ </para>
+ <para>
+ modern virtual machines are based on the idea of <emphasis>hot
+ spots</emphasis>, code fragments that are used often and, if optimized,
+ increase the process execution by far. This new event model allows
+ easier detection of hot spots since it's a method driven operation,
+ rather than a memory driven one. Hot methods can be identified earlier
+ and their optimization performed better.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ reduced garbage collection
+ </para>
+ <para>
+ even the most advanced and lightweight DOM implementation require at
+ least three to five times (and sometimes much more than this) more
+ memory than original document size. This does not only reduce the
+ scalability of the operation, but also impact overall performance by
+ increasing the number of memory garbage that must be collected after
+ the response in sent to the client. Even if modern virtual machines
+ reduced the overhead of garbage collection, less garbage will always
+ have performance and scalability impacts.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The above points, alone, would be enough for the Cocoon2 paradigm shift,
+ even if this event based model impacts not only the general architecture of
+ the publishing system but also its internal processing components such as
+ XSLT processing and PDF formatting. These components will require
+ substantial work and maybe design reconsideration to be able to follow a
+ pure event-based model. The Cocoon Project will work closely with the other
+ component projects to be able to influence their operation in this
+ direction.
+ </para>
+</sect1>
+
+<sect1>
+<title>Reactors Reconsidered</title>
+ <para>
+ Another design choice that should be revised is the reactor pattern that
+ was introduced to allow components to be connected in more flexible way. In
+ fact, opposed to the fixed pipe model used up to Cocoon 1.3.1, the reactor
+ approach allows components to be dynamically connected, depending on
+ reaction instructions introduced inside the documents.
+ </para>
+
+ <para>
+ While this at first seemed a very advanced and highly appealing model, it
+ turned out to be a very dangerous approach. The first concern is mainly
+ technical: porting the reactor pattern under an event-based model requires
+ limitations and tradeoffs since the generated events must be cached until a
+ reaction instruction is encountered.
+ </para>
+
+ <para>
+ But even if the technical difficulties are solved, a key limitation
+ remains: there is no single point of management.
+ </para>
+</sect1>
+
+<sect1>
+<title>Management Considerations</title>
+ <para>
+ The web was created to reduce information management costs by distributing
+ them back on information owners. While this model is great for user
+ communities (scientists, students, employees, or people in general) each of
+ them managing small amount of personal information, it becomes impractical
+ for highly centralized information systems where <emphasis>distributed
+ management</emphasis> is simply not practical.
+ </para>
+
+ <para>
+ While in the HTML web model the page format and URL names where the only
+ necessary contracts between individuals to create a world wide web, in more
+ structured information systems the number of contracts increases by a
+ significant factor due to the need of coherence between the hosted
+ information: common style, common design issues, common languages, server
+ side logic integration, data validation, etc...
+ </para>
+
+ <para>
+ It is only under this light that XML and its web model reveal their power:
+ the HTML web model had too little contracts to be able to develop a
+ structured and more coherent distributed information system, reason that is
+ mainly imposed by the lack of good and algorithmically certain information
+ indexing and knowledge seeking. Lacks that tend to degrade the quality of
+ the truly distributed web in favor of more structured web sites (that based
+ their improved site structure on internal contracts).
+ </para>
+
+ <para>
+ The simplification and engineering of web site management is considered one
+ of the most important Cocoon2 goals. This is done mainly by technologically
+ imposing a reduced number of contracts and place them in a hierarchical
+ shape suitable to replace current high-structure web site management
+ models.
+ </para>
+
+ <para>
+ The model that Cocoon2 adopts is the "pyramid model of web
+ contracts" which is outlined in the picture below
+ </para>
+
+ <figure>
+ <title>The Cocoon2 Pyramid Model of Contracts</title>
+ <graphic fileref="pyramid-model.gif"></graphic>
+ </figure>
+
+ <para>
+ and is composed by four different working contexts (the rectangles)
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Management
+ </para>
+ <para>
+ the people that decide what the site should contain, how it should
+ behave and how it should appear
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Content
+ </para>
+ <para>
+ the people responsible to write, own and manage the site content. This
+ context may contain several sub-contexts one for each language used to
+ express page content.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Logic
+ </para>
+ <para>
+ the people responsible for integration with dynamic content generation
+ technologies and database systems.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Style
+ </para>
+ <para>
+ the people responsible for information presentation, look & feel,
+ site graphics and its maintenance.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ and five contracts (the lines)
+ <simplelist>
+ <member>management - content</member>
+ <member>management - logic</member>
+ <member>management - style</member>
+ <member>content - logic</member>
+ <member>content - style</member>
+ </simplelist>
+ </para>
+
+ <para>
+ note that there is no <emphasis>logic - style</emphasis> contract. Cocoon2
+ aims to provide both software and guidelines to allow you to remove such
+ contract.
+ </para>
+</sect1>
+
+<sect1>
+<title>Overlapping contexts and Chain Mapping</title>
+ <para>
+ The above model can be applied only if the different contexts never
+ overlap, otherwise there is no chance of having a single management point.
+ For example, if the W3C-recommended method to link stylesheets to XML
+ documents is used, the content and style contexts overlap and it's
+ impossible to change the styling behavior of the document without changing
+ it. The same is true for the processing instructions used by the Cocoon1
+ reactor to drive the page processing: each stage concur to determine the
+ result thus increasing management and debug complexity. Another overlapping
+ in context contracts is the need for URL-encoded parameters to drive the
+ page output. These overlaps break the pyramid model and increase the
+ management costs.
+ </para>
+
+ <para>
+ In Cocoon2, the reactor pattern will be abandoned in favor of a pipeline
+ mapping technique. This is based on the fact that the number of different
+ contracts is limited even for big sites and grows with a rate that is
+ normally much less than its size.
+ </para>
+
+ <para>
+ Also, for performance reasons, Cocoon2 will try to compile everything that
+ is possibly compilable (pages/XSP into producers, stylesheets into
+ processors, etc...) so, in this new model, the <emphasis>processing
+ chain</emphasis> that generates the page contains (in a direct executable
+ form) all the information/logic that handles the requested resource to
+ generate its response.
+ </para>
+
+ <para>
+ This means that instead of using even-driven request-time DTD
+ interpretation (done in all Cocoon1 processors), these will be either
+ compiled into processors directly (XSLT stylesheet compilation) or compiled
+ into producers using logicsheets and XSP which will remove totally the need
+ for request-time interpretation solutions like DCP that will be removed.
+ </para>
+
+ <note>
+ <para>
+ Some of these features are already present in latest Cocoon 1.x releases
+ but the Cocoon2 architecture will make them central to its new core
+ </para>
+ </note>
+</sect1>
+
+<sect1>
+<title>Sitemap</title>
+ <para>
+ In Cocoon2 terminology, a <emphasis>sitemap</emphasis> is the collection of
+ pipeline matching informations that allow the Cocoon engine to associate
+ the requested URI to the proper response-producing pipeline.
+ </para>
+
+ <para>
+ The sitemap physically represents the central repository for web site
+ administration, where the URI space and its handling is maintained. An
+ example of the sitemap is given below:
+ </para>
+
+<programlisting>
+<![CDATA[
+<source>
+ <sitemap>
+ <process match="/press/en/*.html">
+ <generator type="file" src="/docs/english/press/*.xml"/>
+ <filter type="xslt">
+ <parameter name="stylesheet" value="/styles/simple-press-html.xsl"/>
+ </filter>
+ <serializer type="html"/>
+ </process>
+
+ <process match="/press/en/*.pdf">
+ <generator type="file" src="/docs/english/press/*.xml"/>
+ <filter type="xslt">
+ <parameter name="stylesheet" value="/styles/simple-press-pdf.xsl"/>
+ </filter>
+ <serializer type="pdf"/>
+ </process>
+
+ <process match="/">
+ <matcher type="agent">
+ <parameter name="name" value="Mozilla/5.0">
+ </matcher>
+ <generator type="file" src="/docs/root.xml"/>
+ <filter type="xslt">
+ <parameter name="stylesheet" value="/styles/fancy-XUL-view.xsl"/>
+ </filter>
+ <serializer type="html"/>
+ </process>
+
+ <process match="/">
+ <matcher type="agent">
+ <parameter name="capability" value="text/vnd.wap.wml">
+ </matcher>
+ <generator type="file" src="/docs/root.xml"/>
+ <filter type="xslt">
+ <parameter name="stylesheet" value="/styles/WAP-view.xsl"/>
+ </filter>
+ <serializer type="wap"/>
+ </process>
+
+ <process match="/">
+ <generator type="file" src="/docs/root.xml"/>
+ <filter type="xslt">
+ <parameter name="stylesheet" value="/styles/normal-view.xsl"/>
+ </filter>
+ <serializer type="html"/>
+ </process>
+ </sitemap>
+</source>
+]]>
+</programlisting>
+
+ <note>
+ <para>
+ The sitemap DTD has not yet been standardized and it's not guaranteed to
+ solidify until Cocoon 2.0 is out final. So, the above should be
+ considered just as a preview and not a specification or even a working
+ draft. For more information dig into the development mail list digests.
+ </para>
+ </note>
+</sect1>
+
+<sect1>
+<title>Pre-compilation, Pre-generation and Caching</title>
+ <para>
+ The cache system in Cocoon1 will be ported with no important design changes
+ since it's very flexible and was not polluted by early design constraints
+ since it appeared in later versions. The issue regards static file caching
+ that, no matter what, will always be slower than direct web server caching.
+ </para>
+
+ <para>
+ To be able to put most of the static part job back on the web server (where
+ it belongs), Cocoon2 will greatly improve it's command line operation,
+ allowing the creation of <emphasis>site makefiles</emphasis> that will
+ automatically scan the web site and the source documents and will provide a
+ way to <emphasis>regenerate</emphasis> the static part of a web site
+ (images and tables included!) based on the same XML model used in the
+ dynamic operation version.
+ </para>
+
+ <para>
+ Cocoon2 will, in fact, be the integration between Cocoon1 and Stylebook.
+ </para>
+
+ <para>
+ It will be up to the web server administrator to use static regeneration
+ capabilities on a time basis, manually or triggered by some particular
+ event (database update signal) since Cocoon2 will only provide servlet and
+ command line capabilities. The nice integration is based on the fact that
+ there will be no behavioral difference if the files are dynamically
+ generated in Cocoon2 via the servlet operation and cached internally or
+ pre-generated and served directly by the web server, as long as URI
+ contracts are kept the same by the system administrator (via URL-rewriting
+ or aliasing)
+ </para>
+
+ <para>
+ Also, it will be possible to avoid on-fly page and stylesheet compilation
+ (which make debugging harder) with command lin e pre-compilation hooks that
+ will work like normal compilers from a developer's point of view.
+ </para>
+</sect1>
+
+</chapter>
+</book>
No revision
No revision
1.4.2.7 +1 -1 xml-cocoon2/src/documentation/xdocs/faq/faq-sitemap.xml
Index: faq-sitemap.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/faq/faq-sitemap.xml,v
retrieving revision 1.4.2.6
retrieving revision 1.4.2.7
diff -u -r1.4.2.6 -r1.4.2.7
--- faq-sitemap.xml 12 Dec 2002 09:02:48 -0000 1.4.2.6
+++ faq-sitemap.xml 8 Mar 2003 23:03:05 -0000 1.4.2.7
@@ -274,7 +274,7 @@
Learn more about advanced Sitemap features by downloading the free chapter, <link
href="http://www.newriders.com/books/product.asp?product_id={C3C05052-BE3B-4E06-A60A-13FB40AF58F6}";
>A User's Look at the Cocoon architecture,</link> from Langham and Ziegeler's
<em>Cocoon: Building XML Applications</em> available at the New Riders web site.
</p>
<p>
-Check out a draft XML Schema <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xdocs/drafts/sitemap-2.1-draft.xsd?rev=HEAD&content-type=text/plain";>grammar
for the Cocoon sitemap</link>, and some <link
href="http://outerthought.net/sitemap/";>external documentation</link> generated from
this Schema. A poster diagram of the sitemap structure is also available.
+Check out a draft XML Schema <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.0/src/documentation/xdocs/drafts/sitemap-2.1-draft.xsd?rev=HEAD&content-type=text/plain";>grammar
for the Cocoon sitemap</link>, and some <link
href="http://outerthought.net/sitemap/";>external documentation</link> generated from
this Schema. A poster diagram of the sitemap structure is also available.
</p>
</answer>
</faq>
No revision
No revision
1.1.2.2 +2 -2
xml-cocoon2/src/documentation/xdocs/howto/howto-author-core-docs.xml
Index: howto-author-core-docs.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/howto/howto-author-core-docs.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- howto-author-core-docs.xml 3 Jul 2002 22:50:36 -0000 1.1.2.1
+++ howto-author-core-docs.xml 8 Mar 2003 23:03:05 -0000 1.1.2.2
@@ -62,7 +62,7 @@
<s2 title="4. Do the work" >
<p>
-Perhaps the easiest way to start a new document is to use an existing document as a
template. If you are revising an existing document, make sure you are using the most
recent copy of the document from CVS HEAD. If you aren't working with a local CVS
repository, you can access all CVS files through <link
href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/";>ViewCVS</link>.
+Perhaps the easiest way to start a new document is to use an existing document as a
template. If you are revising an existing document, make sure you are using the most
recent copy of the document from CVS HEAD. If you aren't working with a local CVS
repository, you can access all CVS files through <link
href="http://cvs.apache.org/viewcvs.cgi/cocoon-2.0/";>ViewCVS</link>.
</p>
</s2>
@@ -92,7 +92,7 @@
<s2 title="9. Update any related pages" >
<p>
-If your work impacts the content of other files, for example the menu file (known
as book.xml), consider updating these documents as well. You can validate and check
link targets within all your documents by performing a docs build. If you have a
working copy of the cvs HEAD, run the appropriate build script inside the xml-cocoon2
directory, specifying docs as the build target. Here's an example:
+If your work impacts the content of other files, for example the menu file (known
as book.xml), consider updating these documents as well. You can validate and check
link targets within all your documents by performing a docs build. If you have a
working copy of the cvs HEAD, run the appropriate build script inside the cocoon-2.0
directory, specifying docs as the build target. Here's an example:
</p>
<source>
./build.[sh|bat] docs
1.4.2.2 +2 -2 xml-cocoon2/src/documentation/xdocs/howto/howto-author-faq.xml
Index: howto-author-faq.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/howto/howto-author-faq.xml,v
retrieving revision 1.4.2.1
retrieving revision 1.4.2.2
diff -u -r1.4.2.1 -r1.4.2.2
--- howto-author-faq.xml 7 Jun 2002 19:47:04 -0000 1.4.2.1
+++ howto-author-faq.xml 8 Mar 2003 23:03:05 -0000 1.4.2.2
@@ -54,7 +54,7 @@
FAQs source files are organized in sets of XML files based on separate Cocoon
topics. You will find all FAQ files in src/documentation/xdocs/faq/. Select the faq
topic file most related to your question. If you can't find a related topic for your
question, then create a new FAQ file by copying an existing file, editing it, and
saving it with new filename based on the new topic.
</p>
<p>
-If you plan to edit an existing file, make sure you are working with the most
recent version. The Cocoon project's cvs stores documentation files in multiple
branches. The HEAD and release branches should be in sync for documentation. However,
should there be some unintentional discrepancy, the HEAD branch is more likely to
contain the most recently updated files. If you have a checked-out version of the cvs
HEAD branch, make sure to run a cvs update before beginning your work on any specific
file. If you don't have the cvs HEAD branch, you can obtain a list of <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xdocs/faq/";>all
current FAQ files</link> through browser-based ViewCVS.
+If you plan to edit an existing file, make sure you are working with the most
recent version. The Cocoon project's cvs stores documentation files in multiple
branches. The HEAD and release branches should be in sync for documentation. However,
should there be some unintentional discrepancy, the HEAD branch is more likely to
contain the most recently updated files. If you have a checked-out version of the cvs
HEAD branch, make sure to run a cvs update before beginning your work on any specific
file. If you don't have the cvs HEAD branch, you can obtain a list of <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.0/src/documentation/xdocs/faq/";>all
current FAQ files</link> through browser-based ViewCVS.
</p>
</s2>
@@ -98,7 +98,7 @@
<s2 title="8. Update any related pages" >
<p>
-If you are contributing a new FAQ file, it will help committers if you also edit
the FAQ main (index.xml) and menu (book.xml) files found at
src/documentation/xdocs/faq/ to include links to your new FAQ file. You can validate
these files with their corresponding dtds as specified in their DOCTYPE statements. If
you have a working copy of the cvs HEAD, make sure you check this additional work by
performing a docs build. To do this, run the appropriate build script inside the
xml-cocoon2 directory, specifying docs as the build target. A docs build not only
validates your files but also checks for broken links.</p>
+If you are contributing a new FAQ file, it will help committers if you also edit
the FAQ main (index.xml) and menu (book.xml) files found at
src/documentation/xdocs/faq/ to include links to your new FAQ file. You can validate
these files with their corresponding dtds as specified in their DOCTYPE statements. If
you have a working copy of the cvs HEAD, make sure you check this additional work by
performing a docs build. To do this, run the appropriate build script inside the
cocoon-2.0 directory, specifying docs as the build target. A docs build not only
validates your files but also checks for broken links.</p>
</s2>
1.4.2.3 +1 -1 xml-cocoon2/src/documentation/xdocs/howto/howto-author-howto.xml
Index: howto-author-howto.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/howto/howto-author-howto.xml,v
retrieving revision 1.4.2.2
retrieving revision 1.4.2.3
diff -u -r1.4.2.2 -r1.4.2.3
--- howto-author-howto.xml 3 Jul 2002 22:50:36 -0000 1.4.2.2
+++ howto-author-howto.xml 8 Mar 2003 23:03:05 -0000 1.4.2.3
@@ -130,7 +130,7 @@
<s2 title="14. Update any related pages" >
<p>
-It would help committers if you also edited the How-To main (index.xml) and menu
(book.xml) files found at src/documentation/xdocs/howto/ to include links to your new
How-To. You can validate these files with their corresponding dtds as specified in
their DOCTYPE statements. If you have a working copy of the cvs HEAD, make sure you
check this additional work by performing a docs build. To do this, run the appropriate
build script inside the xml-cocoon2 directory, specifying docs as the build target. A
docs build not only validates your files but also checks for broken links.</p>
+It would help committers if you also edited the How-To main (index.xml) and menu
(book.xml) files found at src/documentation/xdocs/howto/ to include links to your new
How-To. You can validate these files with their corresponding dtds as specified in
their DOCTYPE statements. If you have a working copy of the cvs HEAD, make sure you
check this additional work by performing a docs build. To do this, run the appropriate
build script inside the cocoon-2.0 directory, specifying docs as the build target. A
docs build not only validates your files but also checks for broken links.</p>
</s2>
<s2 title="15. Prepare any related patches" >
1.1.2.2 +1 -1
xml-cocoon2/src/documentation/xdocs/howto/howto-author-snippet.xml
Index: howto-author-snippet.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/howto/howto-author-snippet.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- howto-author-snippet.xml 7 Jun 2002 19:47:04 -0000 1.1.2.1
+++ howto-author-snippet.xml 8 Mar 2003 23:03:05 -0000 1.1.2.2
@@ -99,7 +99,7 @@
<s2 title="9. Update any related pages" >
<p>
-If you are contributing a new Code Snippet file, it will help committers if you
also edit the Code Snippet main (index.xml) and menu (book.xml) files found at
src/documentation/xdocs/snippet/ to include links to your new Snippet file. You can
validate these files with their corresponding dtds as specified in their DOCTYPE
statements. If you have a working copy of the cvs, make sure you check this additional
work by performing a docs build. To do this, run the appropriate build script inside
the xml-cocoon2 directory, specifying docs as the build target. A docs build not only
validates your files but also checks for broken links.
+If you are contributing a new Code Snippet file, it will help committers if you
also edit the Code Snippet main (index.xml) and menu (book.xml) files found at
src/documentation/xdocs/snippet/ to include links to your new Snippet file. You can
validate these files with their corresponding dtds as specified in their DOCTYPE
statements. If you have a working copy of the cvs, make sure you check this additional
work by performing a docs build. To do this, run the appropriate build script inside
the cocoon-2.0 directory, specifying docs as the build target. A docs build not only
validates your files but also checks for broken links.
</p>
</s2>
1.1.2.2 +2 -2
xml-cocoon2/src/documentation/xdocs/howto/howto-flow-debugger.xml
Index: howto-flow-debugger.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/howto/howto-flow-debugger.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- howto-flow-debugger.xml 28 Dec 2002 08:34:08 -0000 1.1.2.1
+++ howto-flow-debugger.xml 8 Mar 2003 23:03:05 -0000 1.1.2.2
@@ -34,7 +34,7 @@
</s1>
<s1 title="Prerequisites">
<p>
- Until Cocoon 2.1 is released, to use the flow debugger you will need a
CVS <link href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/";>version</link> or
development <link href="http://xml.apache.org/from-cvs/xml-cocoon2/";>snapshot</link>
of Cocoon, at least as recent as 7th December 2002.
+ Until Cocoon 2.1 is released, to use the flow debugger you will need a
CVS <link href="http://cvs.apache.org/viewcvs.cgi/cocoon-2.0/";>version</link> or
development <link href="http://xml.apache.org/from-cvs/cocoon-2.0/";>snapshot</link> of
Cocoon, at least as recent as 7th December 2002.
</p>
<p>
You will also need a JavaScript flow based web application, for
example the flow webapp samples that are currently shipped with Cocoon, and you will
need to be running Cocoon on a server that has a display attached (either local or
remote).
@@ -85,7 +85,7 @@
<p>
Once your application is running and awaiting requests, attempt to
access a page that calls a flow function. The invocation will take longer than normal,
but on your server's display you should see the visual debugger being created and
populated with your flow script.
</p>
- <note>Portions of Cocoon's flow script management <link
href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/components/flow/javascript/system.js?rev=HEAD&content-type=text/vnd.viewcvs-markup";>code</link>
will also be viewable in the debugger.</note>
+ <note>Portions of Cocoon's flow script management <link
href="http://cvs.apache.org/viewcvs.cgi/cocoon-2.0/src/java/org/apache/cocoon/components/flow/javascript/system.js?rev=HEAD&content-type=text/vnd.viewcvs-markup";>code</link>
will also be viewable in the debugger.</note>
<p>
A debugger instance is created per JavaScript interpreter. This
means if you make another request to a different sitemap for example, a new debugger
instance will be created alongside the previous one. This allows you to debug flow
scripts locally to the sitemap they are defined in.
</p>
1.1.2.3 +3 -3 xml-cocoon2/src/documentation/xdocs/howto/howto-patch.xml
Index: howto-patch.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/howto/howto-patch.xml,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- howto-patch.xml 7 Jul 2002 05:20:41 -0000 1.1.2.2
+++ howto-patch.xml 8 Mar 2003 23:03:05 -0000 1.1.2.3
@@ -48,7 +48,7 @@
<ul>
<li>The source code of the documents as a local working copy of the CVS
repository. If you are working with the current CVS HEAD then you will
-have already done a <code>'cvs checkout xml-cocoon2'</code>
+have already done a <code>'cvs checkout cocoon-2.0'</code>
(see <link href="../contrib.html#cvshowto">CVS Usage Precis</link>).
However, see below for other ways of obtaining source for diff comparison.
</li>
@@ -80,7 +80,7 @@
<source><![CDATA[
Index: contrib.xml
===================================================================
-RCS file: /home/cvspublic/xml-cocoon2/src/documentation/xdocs/contrib.xml,v
+RCS file: /home/cvspublic/cocoon-2.0/src/documentation/xdocs/contrib.xml,v
retrieving revision 1.7
diff -u -r1.7 contrib.xml
--- contrib.xml 30 Apr 2002 07:44:52 -0000 1.7
@@ -225,7 +225,7 @@
the steps ...
</p>
<ul>
-<li>get the <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xdocs/contrib.xml?rev=HEAD&content-type=text/xml";>relevant
XML file via ViewCVS</link></li>
+<li>get the <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.0/src/documentation/xdocs/contrib.xml?rev=HEAD&content-type=text/xml";>relevant
XML file via ViewCVS</link></li>
<li>save the file to your local disk: <code>./contrib.xml.orig</code></li>
<li>create a copy of the file: <code>./contrib.xml</code></li>
<li>make your modifications and validate the XML</li>
No revision
No revision
1.18.2.12 +11 -11 xml-cocoon2/src/documentation/xdocs/installing/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/installing/index.xml,v
retrieving revision 1.18.2.11
retrieving revision 1.18.2.12
diff -u -r1.18.2.11 -r1.18.2.12
--- index.xml 1 Dec 2002 04:53:05 -0000 1.18.2.11
+++ index.xml 8 Mar 2003 23:03:05 -0000 1.18.2.12
@@ -59,7 +59,7 @@
<s2 title="Download a development snapshot">
<p>
You also can download one of the development snapshots from the
- <link href="http://xml.apache.org/from-cvs/xml-cocoon2/";>CVS
snapshots</link>
+ <link href="http://xml.apache.org/from-cvs/cocoon-2.0/";>CVS snapshots</link>
directory.
</p>
</s2>
@@ -83,7 +83,7 @@
<li>Click admin->login;</li>
<li> When asked for the password: answer "anoncvs" (without quotes);</li>
<li> Click "create->checkout module";</li>
- <li>Module name and path on the server is "xml-cocoon2" (no quotes);</li>
+ <li>Module name and path on the server is "cocoon-2.0" (no quotes);</li>
<li>Choose a dir to put the source code in;</li>
<li>Go to the "Checkout-options" tab and select "By revision/tag/branch"
and enter "HEAD";</li>
@@ -101,13 +101,13 @@
<li>Enter "cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login".</li>
<li>When asked for the password: answer "anoncvs".</li>
<li>Enter "cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic -z3 checkout
- -r HEAD xml-cocoon2". This will create a directory called "xml-cocoon2"
where the
+ -r HEAD cocoon-2.0". This will create a directory called "cocoon-2.0"
where the
Cocoon2 source will be stored.</li>
<li>Wait until cvs has finished.</li>
<li>The Cocoon source is now on your harddrive.</li>
</ol>
<p>In case you want to update your Cocoon source tree to the
- current version, change to the "xml-cocoon2" directory and
+ current version, change to the "cocoon-2.0" directory and
call "cvs -z3 update -d -P".</p>
</s2>
</s1>
@@ -844,7 +844,7 @@
</li>
<li>
- Copy <code>xml-cocoon2/build/cocoon/cocoon.war</code> into
+ Copy <code>cocoon-2.0/build/cocoon/cocoon.war</code> into
<code>tomcat/webapps</code> directory.
</li>
@@ -964,7 +964,7 @@
Use <code>Configure a new Web Application...</code>,
and enter in field "Path URI" full path name of Cocoon
webapplication directory,
- like <code>d:\xml-cocoon2\build\cocoon\webapp</code>,
+ like <code>d:\cocoon-2.0\build\cocoon\webapp</code>,
enter in field "Name" the servlet name
eg. <code>cocoon</code>.
Check the "Deployed" checkbox, and click "Apply".
@@ -1204,7 +1204,7 @@
</ul>
</li>
<li>Copy <code>xerces-XXX.jar</code> and <code>xml-apis.jar</code>
- JAR file from <code>xml-cocoon2/lib/core/</code> to
+ JAR file from <code>cocoon-2.0/lib/core/</code> to
the <code>resin-2.0.x/lib/</code> directory.</li>
</ul>
</li>
@@ -1215,7 +1215,7 @@
<code>servlet-classloader-hack</code> element to <code>true</code>
</li>
- <li>Copy the <code>xml-cocoon2/build/cocoon/cocoon.war</code> WAR file to
<code>resin-2.x/webapps</code> directory
+ <li>Copy the <code>cocoon-2.0/build/cocoon/cocoon.war</code> WAR file to
<code>resin-2.x/webapps</code> directory
</li>
<li>Start Resin as usual</li>
<li>Open the Cocoon welcome page
(<code>http://localhost:8080/cocoon/</code>)</li>
@@ -1298,12 +1298,12 @@
</li>
<li>Install Xerces as default XML parser for JRun by copying
<code>xerces-XXX.jar</code> and <code>xml-apis.jar</code> JAR
- files from the <code>xml-cocoon2/lib/core/</code> to
<code>jrun/lib/ext/</code>
+ files from the <code>cocoon-2.0/lib/core/</code> to
<code>jrun/lib/ext/</code>
directory.
</li>
<li>Update Rhino shipped with JRun with newer version from the Cocoon by
overwriting <code>jrun/lib/rhino.jar</code> JAR file
- with the <code>xml-cocoon2/lib/optional/rhino-1.5r3.jar</code> file.
+ with the <code>cocoon-2.0/lib/optional/rhino-1.5r3.jar</code> file.
</li>
<li>Start JRun admin server.</li>
<li>Start JRun default server.</li>
@@ -1319,7 +1319,7 @@
<li>Congratulations! (hopefully) you should see the Cocoon welcome
page.</li>
</ul>
<note>Instead of deploying WAR file using console, same could be done by
copying
- <code>xml-cocoon2/build/cocoon/webapp</code> under
<code>jrun/servers/default/</code>
+ <code>cocoon-2.0/build/cocoon/webapp</code> under
<code>jrun/servers/default/</code>
directory and adding following lines to the
<code>jrun/servers/default/local.properties</code>:
</note>
No revision
No revision
1.1.2.3 +1 -1 xml-cocoon2/src/documentation/xdocs/userdocs/concepts/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/index.xml,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- index.xml 30 Jun 2002 23:26:55 -0000 1.1.2.2
+++ index.xml 8 Mar 2003 23:03:05 -0000 1.1.2.3
@@ -537,7 +537,7 @@
export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic
cvs login
Password: anoncvs
-cvs checkout xml-cocoon2
+cvs checkout cocoon-2.0
]]></source>
<p>Build sources as per instruction in Install file.</p>
<p>Move the <code>cocoon.war</code> file to <code>$TOMCAT_HOME/webapps</code>
directory.</p>
1.3.2.10 +1 -1
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/sitemap.xml
Index: sitemap.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/sitemap.xml,v
retrieving revision 1.3.2.9
retrieving revision 1.3.2.10
diff -u -r1.3.2.9 -r1.3.2.10
--- sitemap.xml 15 Nov 2002 23:29:16 -0000 1.3.2.9
+++ sitemap.xml 8 Mar 2003 23:03:05 -0000 1.3.2.10
@@ -1164,7 +1164,7 @@
Learn more about advanced Sitemap features by downloading the free chapter, <link
href="http://www.newriders.com/books/product.asp?product_id={C3C05052-BE3B-4E06-A60A-13FB40AF58F6}";
>A User's Look at the Cocoon architecture,</link> from Langham and Ziegeler's
<em>Cocoon: Building XML Applications</em> available at the New Riders web site.
</p>
<p>
- Check out a draft XML Schema <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xdocs/drafts/sitemap-2.1-draft.xsd?rev=HEAD&content-type=text/plain";>grammar
for the Cocoon sitemap</link>, and some <link
href="http://outerthought.net/sitemap/";>external documentation</link>
+ Check out a draft XML Schema <link
href="http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.0/src/documentation/xdocs/drafts/sitemap-2.1-draft.xsd?rev=HEAD&content-type=text/plain";>grammar
for the Cocoon sitemap</link>, and some <link
href="http://outerthought.net/sitemap/";>external documentation</link>
generated from this Schema. A poster diagram of
the sitemap structure is also available.
</p>
1.2.2.2 +2 -2
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/validation.xml
Index: validation.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/validation.xml,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- validation.xml 28 Dec 2002 08:34:08 -0000 1.2.2.1
+++ validation.xml 8 Mar 2003 23:03:05 -0000 1.2.2.2
@@ -138,12 +138,12 @@
<p>
See
-<link
href="http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/tools/src/schematron/README.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup";>xml-cocoon2/tools/src/schematron/README.txt</link>
+<link
href="http://cvs.apache.org/viewcvs.cgi/cocoon-2.0/tools/src/schematron/README.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup";>cocoon-2.0/tools/src/schematron/README.txt</link>
</p>
<p>
See notes in the top of
-xml-cocoon2/src/webapp/WEB-INF/entities/sitemap-v06.rng
+cocoon-2.0/src/webapp/WEB-INF/entities/sitemap-v06.rng
</p>
</s1>
No revision
No revision
1.2.2.2 +2 -2
xml-cocoon2/src/documentation/xdocs/userdocs/serializers/xls-serializer.xml
Index: xls-serializer.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/serializers/xls-serializer.xml,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- xls-serializer.xml 7 Jun 2002 20:04:24 -0000 1.2.2.1
+++ xls-serializer.xml 8 Mar 2003 23:03:06 -0000 1.2.2.2
@@ -74,8 +74,8 @@
for the Cocoon samples. You'll find the HSSF Serializer
examples under "Legacy Formats" from the main samples
page. You can find the source under <link
-
href="http://cvs.apache.org/viewcvs/xml-cocoon2/src/webapp/samples/poi/";>
- xml-cocoon2/src/webapp/samples/poi</link> in the Cocoon
+
href="http://cvs.apache.org/viewcvs/cocoon-2.0/src/webapp/samples/poi/";>
+ cocoon-2.0/src/webapp/samples/poi</link> in the Cocoon
sources.
</p>
</s1>
No revision
No revision
1.12.2.1 +4 -4 xml-cocoon2/src/scratchpad/schecoon/Attic/prj.el
Index: prj.el
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/Attic/prj.el,v
retrieving revision 1.12
retrieving revision 1.12.2.1
diff -u -r1.12 -r1.12.2.1
--- prj.el 2 Apr 2002 04:53:50 -0000 1.12
+++ prj.el 8 Mar 2003 23:03:06 -0000 1.12.2.1
@@ -1,9 +1,9 @@
(jde-project-file-version "1.0")
(jde-set-variables
- '(jde-compile-option-classpath (quote ("" "" "" ""
"~/src/xml-cocoon2/src/scratchpad/schecoon/build/webapp/WEB-INF/classes"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/sisc-1.3.3.jar"
"../../../build/cocoon/classes" "../../../lib/core/avalon-excalibur-4.1.jar"
"../../../lib/core/avalon-framework-4.1.2.jar"
"../../../lib/core/commons-collections-1.0.jar"
"../../../lib/core/commons-httpclient-20011012.jar"
"../../../lib/core/jakarta-regexp-1.2.jar" "../../../lib/core/logkit-1.0.1.jar"
"../../../lib/core/xalan-2.2.0-D14.jar" "../../../lib/core/xerces-1.4.4.jar"
"../../../lib/core/xml-apis.jar" "../../../lib/optional/batik-libs-1.1.1.jar"
"../../../lib/optional/bsf-2.2.jar" "../../../lib/optional/fop-0.20.2.jar"
"../../../lib/optional/hsqldb-1.61.jar" "../../../lib/optional/jimi-1.0.jar"
"../../../lib/optional/jstyle.jar" "../../../lib/optional/jtidy-04aug2000r7-dev.jar"
"../../../lib/optional/lucene-1.2-rc2.jar"
"../../../lib/optional/maybeupload_1-0-5pre3.jar" "../../../lib/optional/resolver.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/rhino1.5r4-continuations-20020320.jar"
"../../../lib/optional/servlet_2_2.jar" "../../../lib/optional/velocity-1.2.jar"
"../../../lib/optional/xmldb-20010924.jar" "../../../lib/sax2.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/jaxen-core-1.0b8.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/saxpath-1.0b6.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/antlr-2.7.2a2.jar")))
+ '(jde-compile-option-classpath (quote ("" "" "" ""
"~/src/cocoon-2.0/src/scratchpad/schecoon/build/webapp/WEB-INF/classes"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/sisc-1.3.3.jar"
"../../../build/cocoon/classes" "../../../lib/core/avalon-excalibur-4.1.jar"
"../../../lib/core/avalon-framework-4.1.2.jar"
"../../../lib/core/commons-collections-1.0.jar"
"../../../lib/core/commons-httpclient-20011012.jar"
"../../../lib/core/jakarta-regexp-1.2.jar" "../../../lib/core/logkit-1.0.1.jar"
"../../../lib/core/xalan-2.2.0-D14.jar" "../../../lib/core/xerces-1.4.4.jar"
"../../../lib/core/xml-apis.jar" "../../../lib/optional/batik-libs-1.1.1.jar"
"../../../lib/optional/bsf-2.2.jar" "../../../lib/optional/fop-0.20.2.jar"
"../../../lib/optional/hsqldb-1.61.jar" "../../../lib/optional/jimi-1.0.jar"
"../../../lib/optional/jstyle.jar" "../../../lib/optional/jtidy-04aug2000r7-dev.jar"
"../../../lib/optional/lucene-1.2-rc2.jar"
"../../../lib/optional/maybeupload_1-0-5pre3.jar" "../../../lib/optional/resolver.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/rhino1.5r4-continuations-20020320.jar"
"../../../lib/optional/servlet_2_2.jar" "../../../lib/optional/velocity-1.2.jar"
"../../../lib/optional/xmldb-20010924.jar" "../../../lib/sax2.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/jaxen-core-1.0b8.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/saxpath-1.0b6.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/antlr-2.7.2a2.jar")))
'(jde-compile-option-command-line-args "-g")
- '(jde-compile-option-sourcepath (quote
("~/src/xml-cocoon2/src/scratchpad/schecoon/src" "~/src/sisc")))
- '(jde-compile-option-directory
"~/src/xml-cocoon2/src/scratchpad/schecoon/build/webapp/WEB-INF/classes")
- '(jde-global-classpath (quote
("~/src/xml-cocoon2/src/scratchpad/schecoon/lib/sisc-1.3.3.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/build/webapp/WEB-INF/classes"
"../../../build/cocoon/classes" "../../../lib/core/avalon-excalibur-4.1.jar"
"../../../lib/core/avalon-framework-4.1.2.jar"
"../../../lib/core/commons-collections-1.0.jar"
"../../../lib/core/commons-httpclient-20011012.jar"
"../../../lib/core/jakarta-regexp-1.2.jar" "../../../lib/core/logkit-1.0.1.jar"
"../../../lib/core/xalan-2.2.0-D14.jar" "../../../lib/core/xerces-1.4.4.jar"
"../../../lib/core/xml-apis.jar" "../../../lib/optional/batik-libs-1.1.1.jar"
"../../../lib/optional/bsf-2.2.jar" "../../../lib/optional/fop-0.20.2.jar"
"../../../lib/optional/hsqldb-1.61.jar" "../../../lib/optional/jimi-1.0.jar"
"../../../lib/optional/jstyle.jar" "../../../lib/optional/jtidy-04aug2000r7-dev.jar"
"../../../lib/optional/lucene-1.2-rc2.jar"
"../../../lib/optional/maybeupload_1-0-5pre3.jar" "../../../lib/optional/resolver.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/rhino1.5r4-continuations-20020320.jar"
"../../../lib/optional/servlet_2_2.jar" "../../../lib/optional/velocity-1.2.jar"
"../../../lib/optional/xmldb-20010924.jar" "../../../lib/sax2.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/jaxen-core-1.0b8.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/saxpath-1.0b6.jar"
"~/src/xml-cocoon2/src/scratchpad/schecoon/lib/antlr-2.7.2a2.jar")))
+ '(jde-compile-option-sourcepath (quote
("~/src/cocoon-2.0/src/scratchpad/schecoon/src" "~/src/sisc")))
+ '(jde-compile-option-directory
"~/src/cocoon-2.0/src/scratchpad/schecoon/build/webapp/WEB-INF/classes")
+ '(jde-global-classpath (quote
("~/src/cocoon-2.0/src/scratchpad/schecoon/lib/sisc-1.3.3.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/build/webapp/WEB-INF/classes"
"../../../build/cocoon/classes" "../../../lib/core/avalon-excalibur-4.1.jar"
"../../../lib/core/avalon-framework-4.1.2.jar"
"../../../lib/core/commons-collections-1.0.jar"
"../../../lib/core/commons-httpclient-20011012.jar"
"../../../lib/core/jakarta-regexp-1.2.jar" "../../../lib/core/logkit-1.0.1.jar"
"../../../lib/core/xalan-2.2.0-D14.jar" "../../../lib/core/xerces-1.4.4.jar"
"../../../lib/core/xml-apis.jar" "../../../lib/optional/batik-libs-1.1.1.jar"
"../../../lib/optional/bsf-2.2.jar" "../../../lib/optional/fop-0.20.2.jar"
"../../../lib/optional/hsqldb-1.61.jar" "../../../lib/optional/jimi-1.0.jar"
"../../../lib/optional/jstyle.jar" "../../../lib/optional/jtidy-04aug2000r7-dev.jar"
"../../../lib/optional/lucene-1.2-rc2.jar"
"../../../lib/optional/maybeupload_1-0-5pre3.jar" "../../../lib/optional/resolver.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/rhino1.5r4-continuations-20020320.jar"
"../../../lib/optional/servlet_2_2.jar" "../../../lib/optional/velocity-1.2.jar"
"../../../lib/optional/xmldb-20010924.jar" "../../../lib/sax2.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/jaxen-core-1.0b8.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/saxpath-1.0b6.jar"
"~/src/cocoon-2.0/src/scratchpad/schecoon/lib/antlr-2.7.2a2.jar")))
'(jde-compile-option-debug (quote ("all" (t nil nil))))
'(jde-compiler "javac"))
No revision
No revision
1.6.2.1 +2 -2 xml-cocoon2/src/scratchpad/webapp/mount/editor/Attic/README
Index: README
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/scratchpad/webapp/mount/editor/Attic/README,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -u -r1.6 -r1.6.2.1
--- README 22 Mar 2002 12:09:59 -0000 1.6
+++ README 8 Mar 2003 23:03:06 -0000 1.6.2.1
@@ -13,7 +13,7 @@
Once cocoon.war file has expanded, copy the directory with the samples from :
- xml-cocoon2/src/scratchpad/webapps/mount/editor
+ cocoon-2.0/src/scratchpad/webapps/mount/editor
to:
@@ -94,4 +94,4 @@
Thanks
-Jeremy Quinn <[EMAIL PROTECTED]>
\ No newline at end of file
+Jeremy Quinn <[EMAIL PROTECTED]>
