cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <john.r.morri...@ntlworld.com>
Subject RE: [C2]: Countdown for going beta
Date Sun, 29 Apr 2001 10:19:28 GMT
I'm just a lurker but...

> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: Sunday, 29 April 2001 10:17 am
> To: cocoon-dev@xml.apache.org
> Subject: [C2]: Countdown for going beta
>
>
> 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.

Yes, most people want this status ASAP.  I know that the company I work for
have been edgy about using C2 because it's "not even of beta quality
yet...".  Of course most of the people at work only have M$'s opinion of
what alpha/beta quality represents...

> 2. Clean up docs and latest bugs for about a month.

After the first beta is released most people who will be playing with it
will be (relatively) experienced java folks.  This (hopefully) will change
with time to include everyone *GRIN*.  Doc's would definitely be required to
stave off the mass of questions to the dev/user lists.

> 3. Do a beta 2 release.
> 4. See if things have stabilized another month.
> 5. Go productive.

What do you mean?  Do you mean release?  Are you not going to have any
release candidates?

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

A separate CVS repository would be easiest for newbies (myself included most
of the time) who are not familiar with branches.  Another possibility would
be to make C2 the main branch and make C1 a maintence branch?

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

I think that this would be a very useful feature to have.  It would save
having to stop/start the container when a xsp page requires a new jar.  Of
course the time required to code this should be weighed against how
frequently this would be done...

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

I don't know.  Most people won't really want to dig into the sources if they
arn't sure something can be done, even if a generator is commented out it's
at least tells people it exists.  Once they know something exists _then_
they can go digging for how it works...?

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

Hope you found my lurker comments useful, I've been playing with C2 in my
own time since it got started.  Personally, I think that it's way better
than .NET/asp and better than jsp.  I can't comment about Velocity as I've
not tried it.  I am trying to get the company I work for to consider using
it and going beta would certainly help.  Keep up the excellent work, and who
knows, if I can maybe I can persuade work to let me help...

John.


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


Mime
View raw message