cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject [C2]: Countdown for going beta
Date Sun, 29 Apr 2001 09:16:49 GMT
Now that we know that Avalon is focusing on May 11 for beta we should go
beta as well some days after (except there are issues which need to be
solved prior to go beta).

I like the plan how avalon will go productive.

1. Do a beta 1 release.
2. Clean up docs and latest bugs for about a month.
3. Do a beta 2 release.
4. See if things have stabilized another month.
5. Go productive.

Is there a need to have a separate CVS repository for C2 to cleaner
separate C1 from C2 and have the ability to label the releases?

Here are the points from the todo-list:

 <action context="code" assigned-to="open">
   Remove dependencies to the javax.servlet classes.
   There are some classes (ResourceReader, Notifier, ContextURLFactory)
   which use directly the javax.servlet classes. These have to be
   removed.  I would suggest to clean up the ResourceReader. As the
   responses of the Readers are now cached by the StreamPipeline, the
   setting of the SC_NOT_MODIFIED status is unnecessary as it is never
   called now. This would remove the dependecy to the javax.servlet
   classes in this case.
  </action>

AFAIK this issues is solved already (could the solver remove it from the
todo list than?)

  <action context="code" assigned-to="open">
   Reloading of jar-files.
   The class-path for the Cocoon-Servlet is only build once when the
   servlet is initialised. If you want to deploy other jar files you
   have to restart the servlet. A reloading of the Cocoon is not
   sufficient. This is not very convenient. Suggestion: When Cocoon is
   reloaded (a new cocoon instance is created then) the classpath is
   rebuild and used.
  </action>

Can someone tell us the status of this?
Is this an issue that must be solved for Beta 1?

  <action context="code" assigned-to="DM">
   Make the evaluation/application of logicsheets in the XSP system
   reliable and usable without hassle to the logicsheet programmer
  </action>

I don't know the status of this. IIRC this issue has to do with Berins
complains about having to declare every namespace in XSP page which are
used by the logicsheets and their logicsheets and so on.

  <action context="code" assigned-to="open">
   Complete (means put everything we know of into even if it has to be
   commented)  the cocoon.xconf file and put descriptions into it
  </action>

Still outstanding but not really relevant for beta 1.

  <action context="code" assigned-to="open">
   Complete (means put everything we know of into even if it has to be
   commented)  the web.xml file and put descriptions into it (similar to
   the httpd.conf file of the web server or the server.xml of Catalina)
  </action>

This is done.

  <action context="code" assigned-to="PR">
   Implement transparent content aggregation at the pipeline level.
  </action>

This is done (might be buggy concerning namespace handling. This is
true for sitemap level aggregation as well)

Note that if someone has issues7needs for the sitemap semantics and/or
changes of API of any Cocoon Interfaces please stand up now. I'd like to
have thoses things stable during the beta phase.

Any other issues?

Any other plan proposals?

Giacomo


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message