Return-Path: 
 <cocoon-dev-return-12956-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 78093 invoked by uid 500); 3 May 2001 15:05:11 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 78052 invoked from network); 3 May 2001 15:05:07 -0000
To: cocoon-dev@xml.apache.org
Subject: Re: AW: [C2]: Countdown for going beta
Message-ID: <988902305.3af173a18aa7b@mail.otego.com>
Date: Thu, 03 May 2001 17:05:05 +0200 (CEST)
From: Giacomo Pati <giacomo@apache.org>
References: <NEBBLPMLKKCJBKEOKNFHCENEEAAA.cziegeler@sundn.de>
In-Reply-To: <NEBBLPMLKKCJBKEOKNFHCENEEAAA.cziegeler@sundn.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.4
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

I've found another outstanding issue faced me today. The commandline mode isn't 
working anymore. It seems that on the way unbinding from the servlet api the 
commandline mode has gone forgotten. If some kind soul likes to have a task than 
here it is.

Make sure C2 is able to generate the site onyl by its own, getting rid of 
stylebook but keeping the DTDs and XSL sheets we have for our xdocs. Any 
volunteers?

Giacomo


Quoting Carsten Ziegeler <cziegeler@sundn.de>:

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

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