You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/04/19 15:45:52 UTC
[C2]: Countdown for going beta
Hi,
now that the two main parts (Caching and ContentAggregation) are implemented
we should have a look at what has to be done for the beta:
Here are the points from out 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>
<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>
<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>
<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>
<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>
<action context="code" assigned-to="PR">
Implement transparent content aggregation at the pipeline level.
</action>
What else has to be done for the beta?
a) We have the ongoing discussion which was started by discussion the sendRedirect()
method. I personally like the approach of compiled Actions (from XSP or whatever)
very much, but as the 1st of may is approaching very fast, we should leave that
for the next version of c2 - which we could make very fast after the 2.0 version.
b) The status of Avalon - we agreed that we only should go beta with a beta
version of Avalon. What's the status there?
Are there more open tasks we should include in the first beta?
>From the list above there are not really big issues open, so I think we could
have a beta at the 1st of may.
What are your comments, suggestions, wishes?
regards Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Countdown for going beta
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi,
>
> What else has to be done for the beta?
>
> a) We have the ongoing discussion which was started by discussion the sendRedirect()
> method. I personally like the approach of compiled Actions (from XSP or whatever)
> very much, but as the 1st of may is approaching very fast, we should leave that
> for the next version of c2 - which we could make very fast after the 2.0 version.
+1 on this POA (Plan Of Attack). I like the idea of compiled actions, but there
is the issue of specifying them in the sitemap. We would have to come up with a
way of marking the compiled actions so the sitemap knows that it needs to compile
them.
Also, don't forget about SiLLy (Simple Logicsheet Language) that was proposed a
while back, and referred to in the Cocoon docs. I think we should do this fast
after the 2.0 version as well.
> b) The status of Avalon - we agreed that we only should go beta with a beta
> version of Avalon. What's the status there?
It looks like we have all decided on the final structure of the class heirarchy
for the framework. CVS is settling down on that project, and I will check with
Peter and Fede to see how soon we are for Avalon 4 beta. Once we hit beta,
the class heirarchy should remain static for a long time--with the possible
exception of the classes in org.apache.excalibur (Avalon specific components
like the DataSources and Component Management Framework).
> Are there more open tasks we should include in the first beta?
Just some robustness testing. Make a quick audit of all the Components in
Cocoon, and make sure that the components only implement one of the LifeStyle
interfaces (ThreadSafe, Poolable, SingleThreaded). Beyond that, I think we are
pretty cool.
> >From the list above there are not really big issues open, so I think we could
> have a beta at the 1st of may.
>
> What are your comments, suggestions, wishes?
I think we are well on our way!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Countdown for going beta
Posted by Peter Donald <do...@apache.org>.
At 11:16 29/4/01 +0200, giacomo wrote:
>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?
+1
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Countdown for going beta
Posted by Berin Loritsch <bl...@apache.org>.
giacomo 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).
Slight correction:
Aiming for May 11 for code freeze, and hopefully beta 1 release shortly afterwards.
We do need to do this according to the Apache standards for releases :)
We have some testlets to write, and then all should be well.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Countdown for going beta
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 30 Apr 2001, Sylvain Wallez wrote:
> 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 ?
as far as i've been able to tell, it works fine. i have not been able to
create a situation in which the same logicsheet is applied twice, nor have
i been able to envision a rational scenario in which circular dependencies
are, in fact, necessary. we could certainly benefit from more people
trying to break it though. :)
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Countdown for going beta
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: AW: [C2]: Countdown for going beta
Posted by Giacomo Pati <gi...@apache.org>.
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 <cz...@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
AW: [C2]: Countdown for going beta
Posted by Carsten Ziegeler <cz...@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
RE: [C2]: Countdown for going beta
Posted by John Morrison <jo...@ntlworld.com>.
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
Re: [C2]: Countdown for going beta
Posted by giacomo <gi...@apache.org>.
On Sun, 29 Apr 2001, Davanum Srinivas wrote:
> Please see below.
>
> --- giacomo <gi...@apache.org> 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).
>
> Can we go beta along with them? on May 11?
Well, I don't know yet if I have the time to do it on May 11th, thus
giving myself a few days to do it :)
>
> > 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.
Do we need release candidates? AFAIR we never had a release
candidate so far, Robin?
>
> Sounds like a plan.
>
> > 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?
>
> Yes, +1 for a separate CVS repository.
Sam, can you open up a repository with the hole C2 history in it but
without being tagged?
>
> > Here are the points 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?
>
> IMHO, This is not needed for Beta1.
Ok.
>
> >
> > <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.
>
> Yes, this is done. Will remove it.
Cool :)
>
> > <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)
>
> We need some samples and expected results from some of the Namespace Guru's. Any volunteers?
Yes, definitely.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Countdown for going beta
Posted by Davanum Srinivas <di...@yahoo.com>.
Please see below.
--- giacomo <gi...@apache.org> 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).
Can we go beta along with them? on May 11?
> 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 like a plan.
> 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?
Yes, +1 for a separate CVS repository.
> Here are the points 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?
IMHO, This is not needed for Beta1.
>
> <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.
Yes, this is done. Will remove it.
> <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)
We need some samples and expected results from some of the Namespace Guru's. Any volunteers?
Thanks,
dims
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2]: Countdown for going beta
Posted by giacomo <gi...@apache.org>.
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