avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From leosim...@apache.org
Subject cvs commit: jakarta-avalon-site/src/documentation/content/xdocs/framework book.xml index.xml
Date Wed, 29 Jan 2003 15:11:38 GMT
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;assigned_to=avalon-dev@jakarta.apache.org"><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;assigned_to=avalon-dev@jakarta.apache.org">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: avalon-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-cvs-help@jakarta.apache.org


Mime
View raw message