> Giacomo Pati wrote:
>
> 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.
>
Sounds great!
> 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?
>
+2
> 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?)
>
Yes, I solved it some weeks ago and removed it also that time
from the todo list...
> <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?
>
My opinion is that this is a very useful (and so required) feature
for developing applications using C2. Always restarting the servlet
engine only to test new versions of a component is very time
consuming.
I would volunteer for this, but I didn't understand right
now the current classloading procedure using the ClassUtils class.
Perhaps if someone can enlighten me, I could have a try on this.
If we don't want/have this in the beta 1 we shouldn't introduce
in afterwards.
> <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?
>
We should keep the changes and additions very small. Nearly everything
can be introduced in a later version of C2 (or even C3?).
> Any other plan proposals?
>
> Giacomo
>
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|