You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by le...@apache.org on 2003/01/29 16:11:38 UTC
cvs commit: jakarta-avalon-site/src/documentation/content/xdocs/framework book.xml index.xml
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&version=unspecified&rep_platform=all&op_sys=all&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&output=most_doomed&links=1&banner=1&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&output=most_doo
-med&links=1&banner=1&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&version=unspecified&rep_platform=all&op_sys=all&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&output=most_doomed&links=1&banner=1&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&output=most_doo
+med&links=1&banner=1&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