leosimons    2003/01/29 07:11:37

  Modified:    src/documentation/content/xdocs index.xml tabs.xml
               src/documentation/content/xdocs/project patches.xml
                        releases.xml
  Removed:     src/documentation/content/xdocs/apps book.xml index.xml
               src/documentation/content/xdocs/excalibur book.xml index.xml
               src/documentation/content/xdocs/framework book.xml index.xml
  Log:
  more changes. Some stuff no longer neccessary, some stuff improved upon.
  
  Revision  Changes    Path
  1.2       +116 -0    jakarta-avalon-site/src/documentation/content/xdocs/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-site/src/documentation/content/xdocs/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml 23 Jan 2003 17:10:48 -0000      1.1
  +++ index.xml 29 Jan 2003 15:11:36 -0000      1.2
  @@ -11,5 +11,121 @@
            <link href="http://jakarta.apache.org/avalon/";>the jakarta pages</link>
            for now.</p>
             </section>
  +    <section>
  +<title>What is it?</title>
  +      <p>
  +       The Avalon project is an effort to create, design, develop and maintain
  +       a common framework and set of components for applications written
  +       using the Java language.
  +      </p>
  +      <p>
  +      Having said that, what Avalon 'is', is a framework that allows components of 
varying
  +      scale to be created, managed via a specific set of
  +      <link 
href="http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html";>lifecycle</link>
 methods,
  +      and used in an application. While Avalon is geared towards server-side 
applications,
  +      it is not limited to such, and is quite flexible.
  +      </p>
  +      <p>
  +      The scope of usage for Avalon is quite broad. You may only want to create 
custom, application
  +      specific components that can be managed in a well defined manner, or you may 
want to use the many
  +      components and services available with the
  +      <link 
href="http://jakarta.apache.org/avalon/excalibur/index.html";>Excalibur</link>
  +      sub-project, or use complete applications, such as FTP or a web server, in a 
server oriented
  +      container such as Phoenix. What this means to you is that you can use only 
what you need to use,
  +      and you can scale your usage of Avalon as your application needs grow.
  +      </p>
  +    </section>
  +    <section>
  +<title>Project Goals</title>
  +      <p>
  +        As many people point out, software engineering is a very uncommon procedure
  +        in software development and even more uncommon in auto-organized open
  +        source projects. The main goal of this project is to design a way for
  +        different projects to share resources avoiding as much as possible efforts
  +        duplication.
  +      </p>
  +      <p>
  +        The Avalon Team are proud to announce a new whitepaper that covers how
  +        to develop with Avalon. It covers the Framework, and touches on the
  +        LogKit and Excalibur. You can find
  +        <link 
href="http://jakarta.apache.org/avalon/developing/index.html";>Developing with Apache 
Avalon</link>
  +        on this site.
  +      </p>
  +    </section>
  +    <section>
  +<title>Sub-Projects</title>
  +      <p>
  +        There are several distinct sub-projects that together form the Avalon 
project:
  +      </p>
  +
  +      <section>
  +<title>Framework</title>
  +        <p>
  +          <link 
href="http://jakarta.apache.org/avalon/framework/index.html";>Framework</link> provides 
a specification of
  +          design patterns and rules in the form of interfaces. Also provided are 
default
  +          implementations of those interfaces.
  +        </p>
  +        <p>
  +          The framework is not a product or an API set or a set of interfaces: it is
  +          a collection of code design patterns, rules, guidelines and suggestions 
on how to
  +          write software that "plugs" into the framework. The framework does not
  +          impose restrictions on the application that uses it, but rather precious 
guidelines to
  +          help the developers reuse as much work they can from other solutions.
  +        </p>
  +      </section>
  +
  +      <section>
  +<title>Excalibur</title>
  +        <p>
  +          <link 
href="http://jakarta.apache.org/avalon/excalibur/index.html";>Excalibur</link> is a 
collection of
  +          implementations and common code based on and implementing the
  +          <link href="http://jakarta.apache.org/avalon/framework/index.html";>Avalon 
Framework</link>.
  +        </p>
  +      </section>
  +
  +      <section>
  +<title>Phoenix</title>
  +        <p>
  +          <link 
href="http://jakarta.apache.org/avalon/phoenix/index.html";>Phoenix</link> is a server 
oriented
  +          Application Server. Applications and Services that conform to the 
framework
  +          rules can be hosted in Phoenix. The Application server manages the 
applications
  +          classloader, security and logging needs. It also provides a JMX-based 
management
  +          facility.
  +        </p>
  +      </section>
  +
  +      <section>
  +<title>Cornerstone</title>
  +        <p>
  +          <link 
href="http://jakarta.apache.org/avalon/cornerstone/index.html";>Cornerstone</link> is a 
repository.
  +          for what we call <link href="phoenix/what-is-a-block.html">blocks</link>,
  +          which provide services vital to server applications. The blocks include 
blocks for
  +          services such as scheduling and socket management.
  +        </p>
  +      </section>
  +
  +      <section>
  +<title>Applications</title>
  +        <p>
  +          <link 
href="http://jakarta.apache.org/avalon/apps/index.html";>Applications</link> is a 
repository of
  +          Phoenix blocks.  Some are simple self-contained demos of Phoenix 
applications,
  +          others are complete standalone products, and a few are ambitious works in 
progress.
  +          If you are looking for a starting point for a Phoenix block or a complete 
server,
  +          then these applications could be good inspiration.
  +        </p>
  +      </section>
  +
  +      <section>
  +<title>LogKit</title>
  +        <p>
  +          <link 
href="http://jakarta.apache.org/avalon/logkit/index.html";>LogKit</link> is the 
preferred logging toolkit
  +          used by the Avalon subprojects.</p>
  +       <p>
  +       It is quite possible to use the other avalon subprojects without committing 
to logkit.
  +       We support log4j and JDK 1.4 logging as well.
  +       </p>
  +      </section>
  +
  +    </section>
           </body>
       </document>
  
  
  
  1.3       +3 -3      jakarta-avalon-site/src/documentation/content/xdocs/tabs.xml
  
  Index: tabs.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-site/src/documentation/content/xdocs/tabs.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- tabs.xml  24 Jan 2003 16:59:22 -0000      1.2
  +++ tabs.xml  29 Jan 2003 15:11:36 -0000      1.3
  @@ -7,9 +7,9 @@
           xmlns:xlink="http://www.w3.org/1999/xlink";>
   
           <tab label="Home" dir=""/>
  -        <tab label="Framework" dir="framework/"/>
  +        <tab label="Framework" dir="http://avalon.apache.org/framework/"/>
           <tab label="Components" dir="components/"/>
  -        <tab label="Phoenix" dir="phoenix/"/>
  +        <tab label="Phoenix" dir="http://avalon.apache.org/phoenix/"/>
           <tab label="SECA" dir="seca/"/>
  -        <tab label="Apps" dir="apps/"/>
  +        <tab label="Apps" dir="http://avalon.apache.org/apps/"/>
       </tabs>
  
  
  
  1.2       +32 -67    
jakarta-avalon-site/src/documentation/content/xdocs/project/patches.xml
  
  Index: patches.xml
  ===================================================================
  RCS file: 
/home/cvs/jakarta-avalon-site/src/documentation/content/xdocs/project/patches.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- patches.xml       27 Jan 2003 13:34:37 -0000      1.1
  +++ patches.xml       29 Jan 2003 15:11:36 -0000      1.2
  @@ -2,78 +2,43 @@
         <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" 
"document-v11.dtd">
         <document> 
           <header> 
  -          <title>Apache Avalon project: Release Planning</title> 
  +          <title>Apache Avalon project: Patches and Bugrepors</title> 
           </header> 
           <body>
          <section>
  -         <title>Not written yet....</title>
  -         <p>We haven't got our release process written down yet.</p>
  +         <title>Bugzilla!</title>
  +         <p>It's not perfect. But it is the issue tracking system we use, and
  +         we ask that you do, too.<br/>
  +         <br/>
  +         <link 
href="http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Avalon&amp;version=unspecified&amp;rep_platform=all&amp;op_sys=all&amp;[EMAIL PROTECTED]";><strong>Enter
 a bug</strong></link><br/>
  +         <br/>
  +         but please make sure the bug you're reporting doesn't exist yet, you 
include
  +         all relevant information, etc etc. See
  +         <link 
href="http://nagoya.apache.org/wiki/apachewiki.cgi?HowDoISubmitUsefulBugReports";>this 
page</link>
  +         for more on how to submit bug reports, or try google.</p>
          </section>
          <section>
  -         <title>Relevant links</title>
  -         <ul>
  -<li><link href="http://jakarta.apache.org/site/decisions.html";>Jakarta decision 
process</link></li>
  -<li><link href="http://httpd.apache.org/dev/release.html";>HTTPD release 
policy</link></li>
  -<li><link 
href="http://nagoya.apache.org/bugzilla/reports.cgi?product=Avalon&amp;output=most_doomed&amp;links=1&amp;banner=1&amp;quip=0";>Bug
 summary</link></li>
  -<li><link href="http://cvs.apache.org/~bodewig/mirror.html";>Distribution Mirroring 
howto</link></li>
  -<li><link href="http://cvs.apache.org/builds/";>Nightly builds</link></li>
  -<li><link href="http://gump.covalent.net/jars/latest/";>Nightly builds: 
jars@covalent</link></li>
  -<li><link href="http://freshmeat.net/articles/view/392/";>Freshmeat on software 
builds</link></li>
  -<li><link href="http://java.sun.com/docs/books/tutorial/jar/sign/signing.html";>Java 
tutorial: jar signing</link></li>
  -<li><link href="http://java.sun.com/j2se/1.4/docs/tooldocs/tools.html#security";>JDK 
Security tool docs</link></li>
  -<li><link 
href="http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/RELEASE-PLAN-4.1.txt";>Tomcat
 4 release plan</link></li>
  -<li><link 
href="http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/Attic/Avalon-4.0-RELEASE-PLAN";>Framework
 4 release plan</link></li>
  -         </ul>
  -       </section>
  -       <section>
  -         <title>Noel's thoughts</title>
  -         <p>Noel J Bergman wrote to avalon-dev:</p>
  -         <source>
  -Q: "Is the Avalon PMC able to define a coordinated Release of all the A4
  -modules such that we know that they all work together?"
  -
  -My primary concern is not the code, but whether or not the Avalon PMC is
  -ready to act on its responsibilities, and do a coordinated Release of A4.  I
  -firmly believe that the Avalon PMC has a responsibility to determine a
  -consistent set of packages that work together, rather than leave it as a
  -Chinese menu for users to figure out.
  -
  -My suggestion is that the Avalon Community make it a priority to take stock
  -of A4, put together a Release Plan, designate a Release Manager, and act as
  -a group to do a Release.  Here are a few items to consider for the Release
  -Plan:
  -
  -  1) Identify bugs and incompatibilities.
  -  2) Decide which ones will be fixed.
  -  3) Decide what other changes are necessary, e.g., packaging.
  -  4) Make the code changes.
  -  5) Test
  -  6) Update the documentation and web site.
  -
  -The documentation on the web site doesn't appear to reflect the past year's
  -changes.  And I'm still bemused over how a COP platform that "is a framework
  -that allows components of varying scale to be created, managed [and] used"
  -is going to explain why Component is deprecated.  But
  -
  -Here are a few useful links:
  -
  -  Jakarta: http://jakarta.apache.org/site/decisions.html
  -  Apache HTTPD release policies: http://httpd.apache.org/dev/release.html
  -  Avalon bug summary:
  -http://nagoya.apache.org/bugzilla/reports.cgi?product=Avalon&amp;output=most_doo
  -med&amp;links=1&amp;banner=1&amp;quip=0
  -  Mirroring: http://cvs.apache.org/~bodewig/mirror.html
  -
  -Subsequent to the Release, I would suggest that the Avalon Community
  -consider how best to focus its resources.  From what I seem to be hearing
  -from Paul and others regarding the state of the code and the possibilities
  -for proper interoperation between A4 containers, I am beginning to believe
  -that the best option is for the Community to put A4 in maintenance mode, and
  -focus on A5.  But, again, that is something for the Avalon Community to
  -decide after doing a Release.
  -
  -     --- Noel
  -         </source>
  +         <title>Submitting patches</title>
  +         <p>Generate patches using <code>cvs diff -u</code>, or <code>diff 
-u</code>.
  +         Please create your patches relative to the root of the cvs module the patch
  +         should be applied to. Please compile changes to multiple files
  +         in a single patch file. Make sure the patch adheres to the coding 
standards,
  +         and includes appropriate javadoc.</p>
  +         
  +         <p>When you've built the patch, file a new bug report in bugzilla if one
  +         does not exist yet, explain the reason behind the patch, how the patch 
fixes
  +         the issues, and add the patch as an attachment.</p>
  +         
  +         <p>If your patch is not getting applied or there is no response, start 
nagging
  +         the developers (politely, please :D) on the development mailing list.</p>
  +         
  +         <section>
  +           <title>Documentation patches</title>
  +           <p>Please submit documentation patches against the xml sourcefiles used
  +           for generating the documentation, and not against the documentation
  +           itself.</p>
  +         </section>
          </section>
           </body>
       </document>
  +
  
  
  
  1.2       +67 -30    
jakarta-avalon-site/src/documentation/content/xdocs/project/releases.xml
  
  Index: releases.xml
  ===================================================================
  RCS file: 
/home/cvs/jakarta-avalon-site/src/documentation/content/xdocs/project/releases.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- releases.xml      27 Jan 2003 13:34:37 -0000      1.1
  +++ releases.xml      29 Jan 2003 15:11:36 -0000      1.2
  @@ -2,41 +2,78 @@
         <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" 
"document-v11.dtd">
         <document> 
           <header> 
  -          <title>Apache Avalon project: Patches and Bugrepors</title> 
  +          <title>Apache Avalon project: Release Planning</title> 
           </header> 
           <body>
          <section>
  -         <title>Bugzilla!</title>
  -         <p>It's not perfect. But it is the issue tracking system we use, and
  -         we ask that you do, too.<br/>
  -         <br/>
  -         <b><link 
href="http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Avalon&amp;version=unspecified&amp;rep_platform=all&amp;op_sys=all&amp;[EMAIL PROTECTED]";>Enter
 a bug</link></b><br/><br/>
  -         but please make sure the bug you're reporting doesn't exist yet, you 
include
  -         all relevant information, etc etc. See
  -         <link 
href="http://nagoya.apache.org/wiki/apachewiki.cgi?HowDoISubmitUsefulBugReports";>this 
page</link>
  -         for more on how to submit bug reports, or try google.</p>
  +         <title>Not written yet....</title>
  +         <p>We haven't got our release process written down yet.</p>
          </section>
          <section>
  -         <title>Submitting patches</title>
  -         <p>Generate patches using <code>cvs diff -u</code>, or <code>diff 
-u</code>.
  -         Please create your patches relative to the root of the cvs module the patch
  -         should be applied to. Please compile changes to multiple files
  -         in a single patch file. Make sure the patch adheres to the coding 
standards,
  -         and includes appropriate javadoc.</p>
  -         
  -         <p>When you've built the patch, file a new bug report in bugzilla if one
  -         does not exist yet, explain the reason behind the patch, how the patch 
fixes
  -         the issues, and add the patch as an attachment.</p>
  -         
  -         <p>If your patch is not getting applied or there is no response, start 
nagging
  -         the developers (politely, please :D) on the development mailing list.</p>
  -         
  -         <section>
  -           <title>Documentation patches</title>
  -           <p>Please submit documentation patches against the xml sourcefiles used
  -           for generating the documentation, and not against the documentation
  -           itself.</p>
  -         </section>
  +         <title>Relevant links</title>
  +         <ul>
  +<li><link href="http://jakarta.apache.org/site/decisions.html";>Jakarta decision 
process</link></li>
  +<li><link href="http://httpd.apache.org/dev/release.html";>HTTPD release 
policy</link></li>
  +<li><link 
href="http://nagoya.apache.org/bugzilla/reports.cgi?product=Avalon&amp;output=most_doomed&amp;links=1&amp;banner=1&amp;quip=0";>Bug
 summary</link></li>
  +<li><link href="http://cvs.apache.org/~bodewig/mirror.html";>Distribution Mirroring 
howto</link></li>
  +<li><link href="http://cvs.apache.org/builds/";>Nightly builds</link></li>
  +<li><link href="http://gump.covalent.net/jars/latest/";>Nightly builds: 
jars@covalent</link></li>
  +<li><link href="http://freshmeat.net/articles/view/392/";>Freshmeat on software 
builds</link></li>
  +<li><link href="http://java.sun.com/docs/books/tutorial/jar/sign/signing.html";>Java 
tutorial: jar signing</link></li>
  +<li><link href="http://java.sun.com/j2se/1.4/docs/tooldocs/tools.html#security";>JDK 
Security tool docs</link></li>
  +<li><link 
href="http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/RELEASE-PLAN-4.1.txt";>Tomcat
 4 release plan</link></li>
  +<li><link 
href="http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/Attic/Avalon-4.0-RELEASE-PLAN";>Framework
 4 release plan</link></li>
  +         </ul>
  +       </section>
  +       <section>
  +         <title>Noel's thoughts</title>
  +         <p>Noel J Bergman wrote to avalon-dev:</p>
  +         <source>
  +Q: "Is the Avalon PMC able to define a coordinated Release of all the A4
  +modules such that we know that they all work together?"
  +
  +My primary concern is not the code, but whether or not the Avalon PMC is
  +ready to act on its responsibilities, and do a coordinated Release of A4.  I
  +firmly believe that the Avalon PMC has a responsibility to determine a
  +consistent set of packages that work together, rather than leave it as a
  +Chinese menu for users to figure out.
  +
  +My suggestion is that the Avalon Community make it a priority to take stock
  +of A4, put together a Release Plan, designate a Release Manager, and act as
  +a group to do a Release.  Here are a few items to consider for the Release
  +Plan:
  +
  +  1) Identify bugs and incompatibilities.
  +  2) Decide which ones will be fixed.
  +  3) Decide what other changes are necessary, e.g., packaging.
  +  4) Make the code changes.
  +  5) Test
  +  6) Update the documentation and web site.
  +
  +The documentation on the web site doesn't appear to reflect the past year's
  +changes.  And I'm still bemused over how a COP platform that "is a framework
  +that allows components of varying scale to be created, managed [and] used"
  +is going to explain why Component is deprecated.  But
  +
  +Here are a few useful links:
  +
  +  Jakarta: http://jakarta.apache.org/site/decisions.html
  +  Apache HTTPD release policies: http://httpd.apache.org/dev/release.html
  +  Avalon bug summary:
  +http://nagoya.apache.org/bugzilla/reports.cgi?product=Avalon&amp;output=most_doo
  +med&amp;links=1&amp;banner=1&amp;quip=0
  +  Mirroring: http://cvs.apache.org/~bodewig/mirror.html
  +
  +Subsequent to the Release, I would suggest that the Avalon Community
  +consider how best to focus its resources.  From what I seem to be hearing
  +from Paul and others regarding the state of the code and the possibilities
  +for proper interoperation between A4 containers, I am beginning to believe
  +that the best option is for the Community to put A4 in maintenance mode, and
  +focus on A5.  But, again, that is something for the Avalon Community to
  +decide after doing a Release.
  +
  +     --- Noel
  +         </source>
          </section>
           </body>
       </document>
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to