cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [C2]: Countdown for going beta
Date Mon, 30 Apr 2001 17:03:37 GMT


giacomo a écrit :
> 
> 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.
> 
I came to the conclusion that logicsheet dependency should be expressed
by <?xml-logicsheet?> processing instructions and not namespaces, and
Donald outlined some problems when a logicsheet like esql that generates
class-level declaration is applied more than once. Dims worked on that
to ensure that logicsheet are applied only once, but I don't know the
status of this. Dims ?

>   <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

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


Mime
View raw message