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...@s-und-n.de> on 2002/01/11 11:11:48 UTC
Release Plans (was RE: New Components From Avalon Scratchpad)
Hi Team,
it seems that it is time to think of some release plans.
Thanks to Giacomo we have the new directory structure in our CVS
and thanks to all of us we have a working HEAD cvs, so we can
deprecate the 2.0 branch making the development much easier for
all of us.
So, these questions need to be answered:
a) What is the version of the next release?
b) Are there open problems/bugs which must be fixed?
c) Are there outstanding issues which should go into a next release?
d) What is a possible timeframe for the next release?
Any others?
My personal answers to this are:
a) 2.0.1
b) At least making Deli optional
c) - The reintegration of the components moved to Avalon
- Have more official releases, like final Xalan, final Avalon Framework
and Excalibur etc.
d) This is the hard question. If we have no points for b) and c), we could
do a next release in the next weeks.
So if the vote results in making a release immediately without
integrating
further new features, I would propose a beta for the end of this month
with a feature stop right now!
I would like to have the points mentioned in c) integrated in a next
release,
so perhaps a beta could go out around the end of february.
Comments? Opinions?
Regards
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> >
>
> Hey, that's the negative side of being the release coordinator, you get
> the glory but you also get the blame for mistakes :)
But where's the glory? (Please don't answer, this only meant ironically!)
>
> [anyway, I forgot to place a smile after 'final release' above, it was
> supposed to be ironic]
>
Hey, great, so I can add another beer to the list, right?
Cheers,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Stefano Mazzocchi wrote:
> >
> > Robert Koberg wrote:
> > >
> > > I just downloaded:
> > > http://xml.apache.org/dist/cocoon/cocoon-2.0-bin.zip
> > >
> > > In it there is a README that directs you to read a WARNING that says:
> >
> > That is Carsten forgetting to remove it in the final release.
> >
>
> Yes, just blame me - if noone else is present :(
Hey, that's the negative side of being the release coordinator, you get
the glory but you also get the blame for mistakes :)
[anyway, I forgot to place a smile after 'final release' above, it was
supposed to be ironic]
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>Another reason to make a 2.0.1 *SOOON*!!!
>>
>>[I've been saying this since day one]
>>
>
> [AC or BC ? :)]
Doesn't really matter since they are only two years apart ;p
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Robert Koberg wrote:
> >
> > I just downloaded:
> > http://xml.apache.org/dist/cocoon/cocoon-2.0-bin.zip
> >
> > In it there is a README that directs you to read a WARNING that says:
>
> That is Carsten forgetting to remove it in the final release.
>
Yes, just blame me - if noone else is present :(
Carsten
> Another reason to make a 2.0.1 *SOOON*!!!
>
> [I've been saying this since day one]
[AC or BC ? :)]
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> I just downloaded:
> http://xml.apache.org/dist/cocoon/cocoon-2.0-bin.zip
>
> In it there is a README that directs you to read a WARNING that says:
That is Carsten forgetting to remove it in the final release.
Another reason to make a 2.0.1 *SOOON*!!!
[I've been saying this since day one]
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT] RE: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > I guess my irony is blocked by my new ADSL somehow :)
>
> "Good morning, Charlie!" (c) Charles Angels
>
> I see that you shiny new ADSL did not helped against "Stefano bursts":
> they just getting worse - it happens now more often!
> ;)
Yeah, ehmmm, well... :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[OT] RE: dynamic sitemap?
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> I guess my irony is blocked by my new ADSL somehow :)
"Good morning, Charlie!" (c) Charles Angels
I see that you shiny new ADSL did not helped against "Stefano bursts":
they just getting worse - it happens now more often!
;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> I am not try to 'spark' friction.
I guess my irony is blocked by my new ADSL somehow :)
> I do know that I can come off harsh,
> sometimes. I'm not a warm-fuzzy kind-of-guy. I just downloaded c2 and the
> first button in my toolbar is 'Add Folder' (that is the first thing I am
> trying to port over). I am confused on how to proceed. I just picked up java
> a few months ago :(
Hey, Rob, do not worry, I was half-joking, you can say what you want
around here. This is what "open" means.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
I am not try to 'spark' friction. I do know that I can come off harsh,
sometimes. I'm not a warm-fuzzy kind-of-guy. I just downloaded c2 and the
first button in my toolbar is 'Add Folder' (that is the first thing I am
trying to port over). I am confused on how to proceed. I just picked up java
a few months ago :(
-Rob
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 4:45 AM
Subject: Re: dynamic sitemap?
> Robert Koberg wrote:
> >
> > I see from some archives that SM does not like dynamic sitemaps. My tool
> > needs dynamic sitemaps.
>
> Uh, uh, look, somebody is trying to ignite forking friction? :)
>
> I don't like dynamic sitemaps and read my next mail to understand why.
>
> Moreover, nobody ever could come up with a meaningful example that
> *required* the use of a dynamic sitemap.
>
> But maybe you can. I'm all ears.
>
> > Would cocoon be the wrong choice?
>
> Hey, nobody here claims that Cocoon is the tool of choice for
> everything. If you like it, use it, if you don't, don't.
>
> And if you think there is something we can fix, help us fix it.
>
> > I mean does the
> > burden of recompiling the sitemap on each update make it impractical?
>
> Sure it does. I hate it myself!
>
> That's exactly why we have *two* efforts underway to reduce the 'sitemap
> try/test/retry' cycle faster (Sylvain's and Ovidiu's). Checkout the
> 'scratchpad' directory in CVS.
>
> Look, I *love* when I am proven wrong since that's the moment I can
> learn something.
>
> But sparkling friction is not exactly the way I consider 'costructive' a
> critic to be.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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
Re: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> From: "Stefano Mazzocchi" <st...@apache.org>
>
> > Robert Koberg wrote:
> > >
>
> > But I strongly doubt this will need a dynamic sitemap implementation: it
> > need a powerful sitemap editing solution, that is correct, but that's a
> > different story.
>
> what is the story?
The story is that this sitemap editors should not require cocoon
architectural changes (if it does, we have a problem!)
> ---
>
> How do you deliver current information about the site to another application
> located outside the jvm? (for example, to export a site at any time).
I don't know, there are many possible solutions for this.
> Or how does an outside app get site information? (for example, instead of
> the site being pushed to the next level it is pulled)
Ditto.
> And how do you do this without dragging down everybody (everysite) else who
> is using the machine?
>
> maybe these are cocoon-user's questions??
Up to you, but I suggest you to describe your scenario of use in more
detail if you really want some valuable information.
> <snip/>
>
> > Fast and easy sitemap editing cycles and sitemap dynamism are two
> > different things and belong to two very different concern islands.
>
> I don't understand this. If you edit the sitemap then you are changing it.
> Then you need to re-use it. Isn't that dynamic?
I think it's a terminology misunderstanding: we consider 'dynamic' a
sitemap that is changed by the sitemap itself, not a sitemap that is
changed from that outside.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
From: "Vadim Gritsenko" <va...@verizon.net>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > Robert Koberg wrote:
> > >
> > > one more I forgot...
> > >
> > > How do I alter (sub)sitemap information in an app that is not cocoon
> based
> > > (perhaps different jvm, perhaps not) and then get that into cocoon?
> >
> > there is no way to 'upload' something to cocoon remotely.
> >
> > I want to fix this ASAP (I'll do this in the next few days).
>
> I guess you are going to put changes into scratchpad? I still hope for
> soon 2.0.1 release...
>
> And, you still can use FTP or file system in the mean time ;)
>
> Vadim
The company I was contracting to for the last 3 years would not allow FTP
because of security issues (I got around it with ssh and wget/curl but a
producer/editor can't do that). In large site structures there is not just
SoC but SoL (which can have two meanings :) but I will go with 'Separation
of Labor' :). In my experience, the better network admins are taking more
and more 'power' away from (dev)users to avoid security problems. There
needs to be a way in the publ sys to alter and promote a site(s) (this is
big and I see no strategy/workfolw built into cocoon).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > Robert Koberg wrote:
> > >
> > > one more I forgot...
> > >
> > > How do I alter (sub)sitemap information in an app that is not cocoon
> based
> > > (perhaps different jvm, perhaps not) and then get that into cocoon?
> >
> > there is no way to 'upload' something to cocoon remotely.
> >
> > I want to fix this ASAP (I'll do this in the next few days).
>
> I guess you are going to put changes into scratchpad? I still hope for
> soon 2.0.1 release...
no, no software. I mean to fire out an RT to talk about it.
> And, you still can use FTP or file system in the mean time ;)
or webdav over SSL or scp for something more secure.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: dynamic sitemap?
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Robert Koberg wrote:
> >
> > one more I forgot...
> >
> > How do I alter (sub)sitemap information in an app that is not cocoon
based
> > (perhaps different jvm, perhaps not) and then get that into cocoon?
>
> there is no way to 'upload' something to cocoon remotely.
>
> I want to fix this ASAP (I'll do this in the next few days).
I guess you are going to put changes into scratchpad? I still hope for
soon 2.0.1 release...
And, you still can use FTP or file system in the mean time ;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> one more I forgot...
>
> How do I alter (sub)sitemap information in an app that is not cocoon based
> (perhaps different jvm, perhaps not) and then get that into cocoon?
there is no way to 'upload' something to cocoon remotely.
I want to fix this ASAP (I'll do this in the next few days).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
one more I forgot...
How do I alter (sub)sitemap information in an app that is not cocoon based
(perhaps different jvm, perhaps not) and then get that into cocoon?
best,
-Rob
From: "Robert Koberg" <ro...@koberg.com>
> From: "Stefano Mazzocchi" <st...@apache.org>
>
> > Robert Koberg wrote:
> > >
>
> > But I strongly doubt this will need a dynamic sitemap implementation: it
> > need a powerful sitemap editing solution, that is correct, but that's a
> > different story.
>
> what is the story?
>
> ---
>
> How do you deliver current information about the site to another
application
> located outside the jvm? (for example, to export a site at any time).
>
> Or how does an outside app get site information? (for example, instead of
> the site being pushed to the next level it is pulled)
>
> And how do you do this without dragging down everybody (everysite) else
who
> is using the machine?
>
> maybe these are cocoon-user's questions??
>
>
> <snip/>
>
> > Fast and easy sitemap editing cycles and sitemap dynamism are two
> > different things and belong to two very different concern islands.
>
> I don't understand this. If you edit the sitemap then you are changing it.
> Then you need to re-use it. Isn't that dynamic?
>
>
> ---------------------------------------------------------------------
> 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
Re: dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
From: "Stefano Mazzocchi" <st...@apache.org>
> Robert Koberg wrote:
> >
> But I strongly doubt this will need a dynamic sitemap implementation: it
> need a powerful sitemap editing solution, that is correct, but that's a
> different story.
what is the story?
---
How do you deliver current information about the site to another application
located outside the jvm? (for example, to export a site at any time).
Or how does an outside app get site information? (for example, instead of
the site being pushed to the next level it is pulled)
And how do you do this without dragging down everybody (everysite) else who
is using the machine?
maybe these are cocoon-user's questions??
<snip/>
> Fast and easy sitemap editing cycles and sitemap dynamism are two
> different things and belong to two very different concern islands.
I don't understand this. If you edit the sitemap then you are changing it.
Then you need to re-use it. Isn't that dynamic?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> ----- Original Message -----
> From: "Stefano Mazzocchi" <st...@apache.org>
>
> > I don't like dynamic sitemaps and read my next mail to understand why.
> >
> > Moreover, nobody ever could come up with a meaningful example that
> > *required* the use of a dynamic sitemap.
> >
> > But maybe you can. I'm all ears.
> >
>
> To me (and I am sure others) there are 3 phases and 3 sites/VMs to
> developing a website et al:
> - dev.site.com
> - qa.site.com
> - live.site.com
>
> I think it would be good if cocoon could handle these. For dev, the team is
> usually small and would work most efficiently if everything was able to be
> dynamic (and used a storyboarding tool to layout the site :). qa and live
> would be exactly the same and compiled. Perhaps dev and qa are supposed to
> be on one machine and live is on your big machine.
> ---
> It would also be nice to have promotion abilities. Perhaps by reading the
> dynamic properties set[1] during the dev phase the system determines when
> the site is promoted to qa, then to live.
>
> best,
> -Rob
>
> [1] Properties set through a gui like:
> - authors signing off on individual content pieces
> - editors signing off on pages
> - producers signing off on folders/sites
> - etc
> when all these are set to 'go' or something the site is preomoted to the
> next level.
What you are asking for is what I personally call a Content Management
System, ie. the backend of a publishing system
[user] <- PS <- CMS <- [developer]
or, even better
[user] <- KMS <- [developer]
where KMS stands for Knowledge Management System (integrating PS + CMS).
Believe me, this is exactly the direction I want to go because I need it
for my own needs (both personal and professional).
But I strongly doubt this will need a dynamic sitemap implementation: it
need a powerful sitemap editing solution, that is correct, but that's a
different story.
For example, when you write your java code, you don't complain because
java code doesn't dynamically recompiles itself, you complain because
either your compiler is slow, your IDE sucks or your classloader is
broken.
Fast and easy sitemap editing cycles and sitemap dynamism are two
different things and belong to two very different concern islands.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
>
> > I don't like dynamic sitemaps and read my next mail to understand why.
> >
> > Moreover, nobody ever could come up with a meaningful example that
> > *required* the use of a dynamic sitemap.
> >
> > But maybe you can. I'm all ears.
> >
>
> To me (and I am sure others) there are 3 phases and 3 sites/VMs to
> developing a website et al:
> - dev.site.com
> - qa.site.com
> - live.site.com
>
> I think it would be good if cocoon could handle these. For dev, the team
is
> usually small and would work most efficiently if everything was able to be
> dynamic (and used a storyboarding tool to layout the site :). qa and live
> would be exactly the same and compiled. Perhaps dev and qa are supposed to
> be on one machine and live is on your big machine.
If I get you right, what you are describing is something like an
adminitrative interface for the sitemap. Something like that is available in
Jakarta Struts - you have special administrative URLs where you can
add/delete an action, form bean, etc. I think that something like that is
possible with Cocoon too.
If you need a dynamic sitemap at runtime then you can use selector to
dynamically select processing paths, you can use more generic pipelines,
etc. Look at the <map:mount /> - using it you can achieve something like a
dynamic sitemap.
> ---
> It would also be nice to have promotion abilities. Perhaps by reading the
> dynamic properties set[1] during the dev phase the system determines when
> the site is promoted to qa, then to live.
>
> best,
> -Rob
>
> [1] Properties set through a gui like:
> - authors signing off on individual content pieces
> - editors signing off on pages
> - producers signing off on folders/sites
> - etc
> when all these are set to 'go' or something the site is preomoted to the
> next level.
>
>
> ---------------------------------------------------------------------
> 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
Re: dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
> I don't like dynamic sitemaps and read my next mail to understand why.
>
> Moreover, nobody ever could come up with a meaningful example that
> *required* the use of a dynamic sitemap.
>
> But maybe you can. I'm all ears.
>
To me (and I am sure others) there are 3 phases and 3 sites/VMs to
developing a website et al:
- dev.site.com
- qa.site.com
- live.site.com
I think it would be good if cocoon could handle these. For dev, the team is
usually small and would work most efficiently if everything was able to be
dynamic (and used a storyboarding tool to layout the site :). qa and live
would be exactly the same and compiled. Perhaps dev and qa are supposed to
be on one machine and live is on your big machine.
---
It would also be nice to have promotion abilities. Perhaps by reading the
dynamic properties set[1] during the dev phase the system determines when
the site is promoted to qa, then to live.
best,
-Rob
[1] Properties set through a gui like:
- authors signing off on individual content pieces
- editors signing off on pages
- producers signing off on folders/sites
- etc
when all these are set to 'go' or something the site is preomoted to the
next level.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> I see from some archives that SM does not like dynamic sitemaps. My tool
> needs dynamic sitemaps.
Uh, uh, look, somebody is trying to ignite forking friction? :)
I don't like dynamic sitemaps and read my next mail to understand why.
Moreover, nobody ever could come up with a meaningful example that
*required* the use of a dynamic sitemap.
But maybe you can. I'm all ears.
> Would cocoon be the wrong choice?
Hey, nobody here claims that Cocoon is the tool of choice for
everything. If you like it, use it, if you don't, don't.
And if you think there is something we can fix, help us fix it.
> I mean does the
> burden of recompiling the sitemap on each update make it impractical?
Sure it does. I hate it myself!
That's exactly why we have *two* efforts underway to reduce the 'sitemap
try/test/retry' cycle faster (Sylvain's and Ovidiu's). Checkout the
'scratchpad' directory in CVS.
Look, I *love* when I am proven wrong since that's the moment I can
learn something.
But sparkling friction is not exactly the way I consider 'costructive' a
critic to be.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
sorry, I meant that to go to cocoon-users. but if you can answer I would not
be opposed :)
----- Original Message -----
From: "Robert Koberg" <ro...@koberg.com>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 3:17 AM
Subject: dynamic sitemap?
> I see from some archives that SM does not like dynamic sitemaps. My tool
> needs dynamic sitemaps. Would cocoon be the wrong choice? I mean does the
> burden of recompiling the sitemap on each update make it impractical?
>
> thanks,
> -Rob
>
>
> ---------------------------------------------------------------------
> 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
dynamic sitemap?
Posted by Robert Koberg <ro...@koberg.com>.
I see from some archives that SM does not like dynamic sitemaps. My tool
needs dynamic sitemaps. Would cocoon be the wrong choice? I mean does the
burden of recompiling the sitemap on each update make it impractical?
thanks,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ah, sorry, now I see what you mean!
No, the warning is absolutely obsolete and shouldn't be in the
distribution! Cocoon 2.0 is not alpha, it is a final stable release.
Thanks for reporting this!
(Argh, how did that WARNING come into the dist? I thought it was
removed beforehand!)
Regards,
Carsten
> -----Original Message-----
> From: Robert Koberg [mailto:rob@koberg.com]
> Sent: Friday, January 11, 2002 11:40 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Release Plans (was RE: New Components From Avalon
> Scratchpad)
>
>
> I just downloaded:
> http://xml.apache.org/dist/cocoon/cocoon-2.0-bin.zip
>
> In it there is a README that directs you to read a WARNING that says:
>
> ***************************** W A R N I N G
> **********************************
>
> All user accessible points in this software package are to be considered
> "alpha". This means that the developer team is not investing
> _any_ effort
> in providing back compatibility between alpha releases.
>
> This software will continue to be released as "alpha" until both code,
> schemas and APIs will be considered stable.
>
> Until then, there will be no warranty that newer versions will maintain
> back
> compatibility even in the most simple cases.
>
> On the other hand, once "beta" status is reached, back incompatible
> changes
> will be made only if absolutely necessary to reach "final" status.
>
> The Cocoon development team understands the importance of reliable
> software as well as the importance of protecting user
> investiments by the
> creation of a solid development platform that doesn't change.
>
> On the other hand, being the Cocoon project a pioneer in many fields and
> being most of the technologies used at a "working draft" phase
> only, this
> cannot be guaranteed before a final status is reached for the software.
>
> Until then, no effort will be provided to guarantee back compatibility.
>
> You have been warned.
>
> ***************************** W A R N I N G
> **********************************
>
>
>
> ----- Original Message -----
> From: "Carsten Ziegeler" <cz...@s-und-n.de>
> To: <co...@xml.apache.org>
> Sent: Friday, January 11, 2002 2:40 AM
> Subject: RE: Release Plans (was RE: New Components From Avalon Scratchpad)
>
>
> > >
> > >
> > > Is the software in alpha now?
> > >
> >
> > The CVS can be considered alpha, yes.
> >
> > Regards
> > Carsten
> > >
> > > >----- Original Message -----
> > > >From: "Carsten Ziegeler" <cz...@s-und-n.de>
> > >
> > >
> > > > Sorry, Robert,
> > > >
> > > > I don't get what you mean. I was not talking of releasing alpha or
> beta,
> > > > I'm talking of doing a stable final release called 2.0.1. Before the
> > > > final release, of course, betas are released called 2.0.1-beta1 or
> > > > something like that.
> > > >
> > > > 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
>
>
> ---------------------------------------------------------------------
> 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
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Robert Koberg <ro...@koberg.com>.
I just downloaded:
http://xml.apache.org/dist/cocoon/cocoon-2.0-bin.zip
In it there is a README that directs you to read a WARNING that says:
***************************** W A R N I N G
**********************************
All user accessible points in this software package are to be considered
"alpha". This means that the developer team is not investing _any_ effort
in providing back compatibility between alpha releases.
This software will continue to be released as "alpha" until both code,
schemas and APIs will be considered stable.
Until then, there will be no warranty that newer versions will maintain
back
compatibility even in the most simple cases.
On the other hand, once "beta" status is reached, back incompatible
changes
will be made only if absolutely necessary to reach "final" status.
The Cocoon development team understands the importance of reliable
software as well as the importance of protecting user investiments by the
creation of a solid development platform that doesn't change.
On the other hand, being the Cocoon project a pioneer in many fields and
being most of the technologies used at a "working draft" phase only, this
cannot be guaranteed before a final status is reached for the software.
Until then, no effort will be provided to guarantee back compatibility.
You have been warned.
***************************** W A R N I N G
**********************************
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 2:40 AM
Subject: RE: Release Plans (was RE: New Components From Avalon Scratchpad)
> >
> >
> > Is the software in alpha now?
> >
>
> The CVS can be considered alpha, yes.
>
> Regards
> Carsten
> >
> > >----- Original Message -----
> > >From: "Carsten Ziegeler" <cz...@s-und-n.de>
> >
> >
> > > Sorry, Robert,
> > >
> > > I don't get what you mean. I was not talking of releasing alpha or
beta,
> > > I'm talking of doing a stable final release called 2.0.1. Before the
> > > final release, of course, betas are released called 2.0.1-beta1 or
> > > something like that.
> > >
> > > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
>
>
> Is the software in alpha now?
>
The CVS can be considered alpha, yes.
Regards
Carsten
>
> >----- Original Message -----
> >From: "Carsten Ziegeler" <cz...@s-und-n.de>
>
>
> > Sorry, Robert,
> >
> > I don't get what you mean. I was not talking of releasing alpha or beta,
> > I'm talking of doing a stable final release called 2.0.1. Before the
> > final release, of course, betas are released called 2.0.1-beta1 or
> > something like that.
> >
> > 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
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Robert Koberg <ro...@koberg.com>.
Is the software in alpha now?
>----- Original Message -----
>From: "Carsten Ziegeler" <cz...@s-und-n.de>
> Sorry, Robert,
>
> I don't get what you mean. I was not talking of releasing alpha or beta,
> I'm talking of doing a stable final release called 2.0.1. Before the
> final release, of course, betas are released called 2.0.1-beta1 or
> something like that.
>
> Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sorry, Robert,
I don't get what you mean. I was not talking of releasing alpha or beta,
I'm talking of doing a stable final release called 2.0.1. Before the
final release, of course, betas are released called 2.0.1-beta1 or
something like that.
Carsten
Robert Koberg wrote:
>
> It seems strange to have that kind of dot version for alpha to
> beta (though
> it seems stranger to release an alpha...). I guess this is similar to how
> apple releases it's OS now :)
>
> Curious, why do you make the user download and decompress to get to:
>
> ***************************** W A R N I N G
> **********************************
>
> All user accessible points in this software package are to be considered
> "alpha". This means that the developer team is not investing
> _any_ effort
> in providing back compatibility between alpha releases.
>
> This software will continue to be released as "alpha" until both code,
> schemas and APIs will be considered stable.
>
> Until then, there will be no warranty that newer versions will maintain
> back
> compatibility even in the most simple cases.
>
> On the other hand, once "beta" status is reached, back incompatible
> changes
> will be made only if absolutely necessary to reach "final" status.
>
> The Cocoon development team understands the importance of reliable
> software as well as the importance of protecting user
> investiments by the
> creation of a solid development platform that doesn't change.
>
> On the other hand, being the Cocoon project a pioneer in many fields and
> being most of the technologies used at a "working draft" phase
> only, this
> cannot be guaranteed before a final status is reached for the software.
>
> Until then, no effort will be provided to guarantee back compatibility.
>
> You have been warned.
>
> ***************************** W A R N I N G
> **********************************
>
> I would think this might be something for the home page or at least
> available at the same level as the distribution so it can be read before
> download.
>
> best,
> -Rob.
>
>
>
>
> ----- Original Message -----
> From: "Carsten Ziegeler" <cz...@s-und-n.de>
> To: "Cocoon-Dev" <co...@xml.apache.org>
> Sent: Friday, January 11, 2002 2:11 AM
> Subject: Release Plans (was RE: New Components From Avalon Scratchpad)
>
>
> > Hi Team,
> >
> > it seems that it is time to think of some release plans.
> > Thanks to Giacomo we have the new directory structure in our CVS
> > and thanks to all of us we have a working HEAD cvs, so we can
> > deprecate the 2.0 branch making the development much easier for
> > all of us.
> >
> > So, these questions need to be answered:
> > a) What is the version of the next release?
> >
> > My personal answers to this are:
> > a) 2.0.1
> > Comments? Opinions?
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Robert Koberg <ro...@koberg.com>.
It seems strange to have that kind of dot version for alpha to beta (though
it seems stranger to release an alpha...). I guess this is similar to how
apple releases it's OS now :)
Curious, why do you make the user download and decompress to get to:
***************************** W A R N I N G
**********************************
All user accessible points in this software package are to be considered
"alpha". This means that the developer team is not investing _any_ effort
in providing back compatibility between alpha releases.
This software will continue to be released as "alpha" until both code,
schemas and APIs will be considered stable.
Until then, there will be no warranty that newer versions will maintain
back
compatibility even in the most simple cases.
On the other hand, once "beta" status is reached, back incompatible
changes
will be made only if absolutely necessary to reach "final" status.
The Cocoon development team understands the importance of reliable
software as well as the importance of protecting user investiments by the
creation of a solid development platform that doesn't change.
On the other hand, being the Cocoon project a pioneer in many fields and
being most of the technologies used at a "working draft" phase only, this
cannot be guaranteed before a final status is reached for the software.
Until then, no effort will be provided to guarantee back compatibility.
You have been warned.
***************************** W A R N I N G
**********************************
I would think this might be something for the home page or at least
available at the same level as the distribution so it can be read before
download.
best,
-Rob.
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: "Cocoon-Dev" <co...@xml.apache.org>
Sent: Friday, January 11, 2002 2:11 AM
Subject: Release Plans (was RE: New Components From Avalon Scratchpad)
> Hi Team,
>
> it seems that it is time to think of some release plans.
> Thanks to Giacomo we have the new directory structure in our CVS
> and thanks to all of us we have a working HEAD cvs, so we can
> deprecate the 2.0 branch making the development much easier for
> all of us.
>
> So, these questions need to be answered:
> a) What is the version of the next release?
>
> My personal answers to this are:
> a) 2.0.1
> Comments? Opinions?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>SNIP
>>
>>>My personal answers to this are:
>>>a) 2.0.1
>>>
>>+1 if absolutely *no* back incompatible changes are introduced.
>>
>>
>
> I'm not aware of an incompatible change. Did I miss one?
DELI incorporation forces Cocoon to use the Deli jar. People who
only want to upgrade the core jars in their webapp will be rudely
surprised.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> SNIP
> > My personal answers to this are:
> > a) 2.0.1
>
> +1 if absolutely *no* back incompatible changes are introduced.
>
I'm not aware of an incompatible change. Did I miss one?
> 2.1 if the above is not true.
>
> > b) At least making Deli optional
>
> +1
>
> > c) - The reintegration of the components moved to Avalon
> > - Have more official releases, like final Xalan, final
> Avalon Framework
> > and Excalibur etc.
>
> +1
>
> > d) This is the hard question. If we have no points for b) and
> c), we could
> > do a next release in the next weeks.
>
> +1, end of January?
>
> > So if the vote results in making a release immediately without
> > integrating
> > further new features, I would propose a beta for the end of
> this month
> > with a feature stop right now!
>
> No, no, no betas or RC, as long as we keep back compatibility we release
> and we go. If a bugfix is needed 2.0.2 will fix it.
>
> > I would like to have the points mentioned in c) integrated in a next
> > release,
> > so perhaps a beta could go out around the end of february.
>
> That's more than a couple of week in my calendar. <puzzled/>
So, it seems easier for all of us, if we do the release "right now", which
would be next week. Right?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi Team,
>
> it seems that it is time to think of some release plans.
> Thanks to Giacomo we have the new directory structure in our CVS
> and thanks to all of us we have a working HEAD cvs, so we can
> deprecate the 2.0 branch making the development much easier for
> all of us.
>
> So, these questions need to be answered:
> a) What is the version of the next release?
>
> b) Are there open problems/bugs which must be fixed?
>
> c) Are there outstanding issues which should go into a next release?
>
> d) What is a possible timeframe for the next release?
>
> Any others?
>
> My personal answers to this are:
> a) 2.0.1
+1 if absolutely *no* back incompatible changes are introduced.
2.1 if the above is not true.
> b) At least making Deli optional
+1
> c) - The reintegration of the components moved to Avalon
> - Have more official releases, like final Xalan, final Avalon Framework
> and Excalibur etc.
+1
> d) This is the hard question. If we have no points for b) and c), we could
> do a next release in the next weeks.
+1, end of January?
> So if the vote results in making a release immediately without
> integrating
> further new features, I would propose a beta for the end of this month
> with a feature stop right now!
No, no, no betas or RC, as long as we keep back compatibility we release
and we go. If a bugfix is needed 2.0.2 will fix it.
> I would like to have the points mentioned in c) integrated in a next
> release,
> so perhaps a beta could go out around the end of february.
That's more than a couple of week in my calendar. <puzzled/>
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Gerhard Froehlich <g-...@gmx.de>.
Berin,
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
>Gerhard Froehlich wrote:
>
>>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>
>>>Gerhard Froehlich wrote:
>>>
>>>
>>>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>>>
>>>>>Hi Team,
>>>>>
>>>>>it seems that it is time to think of some release plans.
>>>>>Thanks to Giacomo we have the new directory structure in our CVS
>>>>>and thanks to all of us we have a working HEAD cvs, so we can
>>>>>deprecate the 2.0 branch making the development much easier for
>>>>>all of us.
>>>>>
>>>>>So, these questions need to be answered:
>>>>>a) What is the version of the next release?
>>>>>
>>>>>b) Are there open problems/bugs which must be fixed?
>>>>>
>>>>>c) Are there outstanding issues which should go into a next release?
>>>>>
>>>>>
>>>>I would like to put the new jisp store and the refactored MRUMemoryStore
>>>>in the new release. I believe that will be a real improvement! Do you tested
>>>>this component? You find it in the scratchpad.
>>>>
>>>
>>>Before you incorporate the cache changes, I would like to see one configuration
>>>for the whole cache. The Cache Janitor is strictly used for the cache, and
>>>can be started and stopped by the MRUMemoryStore directly.
>>>
>>
>> You mean putting all under one <store/> configuration? Under the point that all
>> is "Store", then I like it (+1).
>
>
>Exactly!
Berin, I did some thoughts about that issue. From SoC point of view this will break
the Avalon SoC design. You are right all this components are under the Store package.
But each of them are standalone components (90%), with their own responsibilities.
I don't want to wire this components to much together.
Hmm maybe I'm wrong here, but how would you solve this?
1. each Store component can somehow access the <store/> section in the cocoon.xconf
file. But I don't have a idea how.
2. the MRUMemoryStore configures the rest of the Store compents via public setter,
getter methods.
What do you think?
Gerhard
"God put me on this Earth to accomplish a certain number of things.
Right now, I am so far behind I shall never die."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Gerhard Froehlich wrote:
>>
>>
>>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>>
>>>>Hi Team,
>>>>
>>>>it seems that it is time to think of some release plans.
>>>>Thanks to Giacomo we have the new directory structure in our CVS
>>>>and thanks to all of us we have a working HEAD cvs, so we can
>>>>deprecate the 2.0 branch making the development much easier for
>>>>all of us.
>>>>
>>>>So, these questions need to be answered:
>>>>a) What is the version of the next release?
>>>>
>>>>b) Are there open problems/bugs which must be fixed?
>>>>
>>>>c) Are there outstanding issues which should go into a next release?
>>>>
>>>>
>>>I would like to put the new jisp store and the refactored MRUMemoryStore
>>>in the new release. I believe that will be a real improvement! Do you tested
>>>this component? You find it in the scratchpad.
>>>
>>
>>Before you incorporate the cache changes, I would like to see one configuration
>>for the whole cache. The Cache Janitor is strictly used for the cache, and
>>can be started and stopped by the MRUMemoryStore directly.
>>
>
> You mean putting all under one <store/> configuration? Under the point that all
> is "Store", then I like it (+1).
Exactly!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Gerhard Froehlich <g-...@gmx.de>.
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
>Gerhard Froehlich wrote:
>
>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>
>>>Hi Team,
>>>
>>>it seems that it is time to think of some release plans.
>>>Thanks to Giacomo we have the new directory structure in our CVS
>>>and thanks to all of us we have a working HEAD cvs, so we can
>>>deprecate the 2.0 branch making the development much easier for
>>>all of us.
>>>
>>>So, these questions need to be answered:
>>>a) What is the version of the next release?
>>>
>>>b) Are there open problems/bugs which must be fixed?
>>>
>>>c) Are there outstanding issues which should go into a next release?
>>>
>>
>> I would like to put the new jisp store and the refactored MRUMemoryStore
>> in the new release. I believe that will be a real improvement! Do you tested
>> this component? You find it in the scratchpad.
>
>
>Before you incorporate the cache changes, I would like to see one configuration
>for the whole cache. The Cache Janitor is strictly used for the cache, and
>can be started and stopped by the MRUMemoryStore directly.
You mean putting all under one <store/> configuration? Under the point that all
is "Store", then I like it (+1).
Gerhard
"All the trouble in the world is due to the
fact that man cannot sit still in a room.
(Blaise Pascal)"
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>
>>Hi Team,
>>
>>it seems that it is time to think of some release plans.
>>Thanks to Giacomo we have the new directory structure in our CVS
>>and thanks to all of us we have a working HEAD cvs, so we can
>>deprecate the 2.0 branch making the development much easier for
>>all of us.
>>
>>So, these questions need to be answered:
>>a) What is the version of the next release?
>>
>>b) Are there open problems/bugs which must be fixed?
>>
>>c) Are there outstanding issues which should go into a next release?
>>
>
> I would like to put the new jisp store and the refactored MRUMemoryStore
> in the new release. I believe that will be a real improvement! Do you tested
> this component? You find it in the scratchpad.
Before you incorporate the cache changes, I would like to see one configuration
for the whole cache. The Cache Janitor is strictly used for the cache, and
can be started and stopped by the MRUMemoryStore directly.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Gerhard Froehlich <g-...@gmx.de>.
>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
>Hi Team,
>
>it seems that it is time to think of some release plans.
>Thanks to Giacomo we have the new directory structure in our CVS
>and thanks to all of us we have a working HEAD cvs, so we can
>deprecate the 2.0 branch making the development much easier for
>all of us.
>
>So, these questions need to be answered:
>a) What is the version of the next release?
>
>b) Are there open problems/bugs which must be fixed?
>
>c) Are there outstanding issues which should go into a next release?
I would like to put the new jisp store and the refactored MRUMemoryStore
in the new release. I believe that will be a real improvement! Do you tested
this component? You find it in the scratchpad.
gerhard
<skip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release Plans (was RE: New Components From Avalon Scratchpad)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> Hi Team,
>
> a) What is the version of the next release?
2.0.1
> b) Are there open problems/bugs which must be fixed?
Yes, HSQLDB shutdown. However, I did not come up with good plan yet.
What we had for 2.0 release? IIRC, this was working correctly some time
ago...
> c) Are there outstanding issues which should go into a next release?
I want to include Sitemap syntax changes into 2.0.1
> d) What is a possible timeframe for the next release?
End of Jan is good.
> Any others?
We need to review TODO before cutting release.
> b) At least making Deli optional
+1
> c) - The reintegration of the components moved to Avalon
> - Have more official releases, like final Xalan, final Avalon
Framework
> and Excalibur etc.
-1, let's do it in next one.
> d) This is the hard question. If we have no points for b) and c), we
could
> do a next release in the next weeks.
> So if the vote results in making a release immediately without
integrating
> further new features, I would propose a beta for the end of this
month
> with a feature stop right now!
Can I commit sitemap changes?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org