You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/10/28 16:29:52 UTC
scratchpad blocks
What about having blocks inside the scratchpad? I just wanted to package the
precept stuff but it should not go into the maintrunk. so...
I think scratchpad blocks would unify the pattern of creating new stuff... it
also would be a piece of cake to move things out of the scratchpad then.
On the other hand we could also just create blocks and mark them appropriatly
and exclude them from the standard build.
So we could:
1) leave everything like it is :-(
2) have another blocks directory under scratchpad
3) have a single blocks directory and mark and exclude scratchpad stuff
What do you guys think?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: scratchpad blocks
Posted by Vadim Gritsenko <va...@verizon.net>.
Torsten Curdt wrote:
>>><blocks>
>>> <fop include="true"/>
>>> ...
>>>
>>> <!-- the following blocks are marked unstable and should be
>>> considered being pre-alpha quality. Their API might change
>>> without notice -->
>>> <myteststuff include="false" unstable="true"/>
>>> <scratchpad include="false" unstable="true"/>
>>></blocks>
>>>
>>>Ok?
>>>
>>>
>>Please, don't use unstable="true" or unstable="false", what about
>>status="stable" and status="unstable".
>>This is interpreted in a stylesheet
>>anyway, so please make it more readable for a casual user.
>>
>>
>
>I am fine with that... So I'll go for
>
> <!-- the following blocks are marked unstable and should be
> considered being pre-alpha quality. Their API might change
> without notice -->
> <myteststuff include="false" status="unstable"/>
> <scratchpad include="false" status="unstable"/>
>
>ok?
>
Go ahead :)
Vadim
>>Carsten
>>
>>
>
>back from vacation? ;-)
>--
>Torsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cocoon-2.0.3 portal in a production environment ...
Posted by Stefano Mazzocchi <st...@apache.org>.
SAXESS - Hussayn Dabbous wrote:
> Is it reasonable to use the cocoon portal demo from cocoon-2.0.3 as
> starting point for a productive application running about 20000
> users with about 120 concurrent sessions and
> about 10 major page hits per second (not counting subsequent requests
> for images and so on)
>
> We are currently running a SUN Enterprise 450
> with 4 processors (i think 450 MHz or so...)
> We are using tomcat 4.1.12, but may switch to
> websphere due to customer restrictions...
>
> any hint is welcome.
> regards, Hussayn
>
I don't picture any problem at all with the load/system you describe.
But of course, YMMV.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
cocoon-2.0.3 portal in a production environment ...
Posted by SAXESS - Hussayn Dabbous <da...@saxess.com>.
Is it reasonable to use the cocoon portal demo
from cocoon-2.0.3 as starting point for a
productive application running about 20000
users with about 120 concurrent sessions and
about 10 major page hits per second (not counting
subsequent requests for images and so on)
We are currently running a SUN Enterprise 450
with 4 processors (i think 450 MHz or so...)
We are using tomcat 4.1.12, but may switch to
websphere due to customer restrictions...
any hint is welcome.
regards, Hussayn
--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail: dabbous@saxess.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: build system [was: scratchpad blocks]
Posted by Torsten Curdt <tc...@dff.st>.
On Tuesday 29 October 2002 05:31, Vadim Gritsenko wrote:
> Torsten Curdt wrote:
> >while implementing the scratchpad blocks...
> >
> >>I am fine with that... So I'll go for
> >>
> >> <!-- the following blocks are marked unstable and should be
> >> considered being pre-alpha quality. Their API might change
> >> without notice -->
> >> <myteststuff include="false" status="unstable"/>
> >> <scratchpad include="false" status="unstable"/>
> >
> >...I found some things I like to hear some opinions on before changing the
> >whole build system ;-)
> >
> >1. I found that the status="unstable" should be not in the properties.xml
> > file but the modules.xml file. since that's the file that describes our
> > blocks
> >
> >2. Why is this file called modules.xml?
>
> AFAIU, module.xml is for the gump.
:-/ ...that's what I feared...
> And, while we are on the subject, why, why gump projects / cocoon blocks
> named as "fop-block", and not "cocoon-fop-block"???
true... shall I change it then?
what about the other stuff? I want to tackle that today...
guys - if noone has any comments/objections I will just "make it work" as I
think ;-)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: build system [was: scratchpad blocks]
Posted by Vadim Gritsenko <va...@verizon.net>.
Torsten Curdt wrote:
>while implementing the scratchpad blocks...
>
>
>
>>I am fine with that... So I'll go for
>>
>> <!-- the following blocks are marked unstable and should be
>> considered being pre-alpha quality. Their API might change
>> without notice -->
>> <myteststuff include="false" status="unstable"/>
>> <scratchpad include="false" status="unstable"/>
>>
>>
>
>...I found some things I like to hear some opinions on before changing the
>whole build system ;-)
>
>1. I found that the status="unstable" should be not in the properties.xml file
>but the modules.xml file. since that's the file that describes our blocks
>
>2. Why is this file called modules.xml?
>
AFAIU, module.xml is for the gump.
And, while we are on the subject, why, why gump projects / cocoon blocks
named as "fop-block", and not "cocoon-fop-block"???
Just look at http://jakarta.apache.org/builds/gump/latest/ - isn't it
confusing? One might think that FOP guys come up with some block idea...
Vadim
> Shouldn't it be better named
>blocks.xml? But it also includes the core... Should we have a core block?
>
>3. No matter what I select in the properties.xml (include or not) it seem
>every block gets included (for installwar) - someone else experienced that
>before? (I haven't had time to have a closer look yet)
>
>4. For me it seems like javadocs/documentation as well as the blocks are
>*always* build (for installwar). no matter what is selected in the
>properties.xml. this might of course also be related to 3.
>
>5. Shouldn't we have also a lib directory inside blocks and move the optional
>jars into those directories? So we can easily copy them only if they are
>really needed inside the webapp
>
>6. javadoc spits out dozens of full text lines... warnings and stuff. is that
>really necessary? Cannot remember to have seen it that verbose before...
>Maybe because I switched to jdk1.4 now? (stupid GLIBC_2.0 bug in 1.3)
>
>
>Anyone: before making bigger changes of the build system please talk back to
>me since I have some things waiting to be committed ;-)
>
>Fire off!
>
>it's late - good night :-)
>--
>Torsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
build system [was: scratchpad blocks]
Posted by Torsten Curdt <tc...@dff.st>.
while implementing the scratchpad blocks...
> I am fine with that... So I'll go for
>
> <!-- the following blocks are marked unstable and should be
> considered being pre-alpha quality. Their API might change
> without notice -->
> <myteststuff include="false" status="unstable"/>
> <scratchpad include="false" status="unstable"/>
...I found some things I like to hear some opinions on before changing the
whole build system ;-)
1. I found that the status="unstable" should be not in the properties.xml file
but the modules.xml file. since that's the file that describes our blocks
2. Why is this file called modules.xml? Shouldn't it be better named
blocks.xml? But it also includes the core... Should we have a core block?
3. No matter what I select in the properties.xml (include or not) it seem
every block gets included (for installwar) - someone else experienced that
before? (I haven't had time to have a closer look yet)
4. For me it seems like javadocs/documentation as well as the blocks are
*always* build (for installwar). no matter what is selected in the
properties.xml. this might of course also be related to 3.
5. Shouldn't we have also a lib directory inside blocks and move the optional
jars into those directories? So we can easily copy them only if they are
really needed inside the webapp
6. javadoc spits out dozens of full text lines... warnings and stuff. is that
really necessary? Cannot remember to have seen it that verbose before...
Maybe because I switched to jdk1.4 now? (stupid GLIBC_2.0 bug in 1.3)
Anyone: before making bigger changes of the build system please talk back to
me since I have some things waiting to be committed ;-)
Fire off!
it's late - good night :-)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: scratchpad blocks
Posted by John Morrison <jo...@ntlworld.com>.
On Mon, 28 Oct 2002, Torsten Curdt wrote:
>
> I am fine with that... So I'll go for
>
> <!-- the following blocks are marked unstable and should be
> considered being pre-alpha quality. Their API might change
> without notice -->
> <myteststuff include="false" status="unstable"/>
> <scratchpad include="false" status="unstable"/>
>
> ok?
>
Looks good for me :)
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: scratchpad blocks
Posted by Torsten Curdt <tc...@dff.st>.
> > <blocks>
> > <fop include="true"/>
> > ...
> >
> > <!-- the following blocks are marked unstable and should be
> > considered being pre-alpha quality. Their API might change
> > without notice -->
> > <myteststuff include="false" unstable="true"/>
> > <scratchpad include="false" unstable="true"/>
> > </blocks>
> >
> > Ok?
>
> Please, don't use unstable="true" or unstable="false", what about
> status="stable" and status="unstable".
> This is interpreted in a stylesheet
> anyway, so please make it more readable for a casual user.
I am fine with that... So I'll go for
<!-- the following blocks are marked unstable and should be
considered being pre-alpha quality. Their API might change
without notice -->
<myteststuff include="false" status="unstable"/>
<scratchpad include="false" status="unstable"/>
ok?
> Carsten
back from vacation? ;-)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: scratchpad blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> > > So we could:
> > >
> > > 1) leave everything like it is :-(
> > > 2) have another blocks directory under scratchpad
> > > 3) have a single blocks directory and mark and exclude
> scratchpad stuff
> >
> > 4) have a scratchpad directory in every block that needs it.
> >
> > I'm in favour of 3)
>
> excellent - same here :-)
>
> > We could have a new block "scrachpad-block" (a), append "-scratch" to
> > the name e.g. "new-stuff-scratch-block" (b), or just add a comment in
> > modules.xml saying it is "pre-alpha quality" (c). Either one is
> > fine.
>
> <blocks>
> <fop include="true"/>
> <myteststuff include="false"
>
> scratch="true"
> quality="pre-alpha"
> unstable="true"
> stable="false"
> />
> </blocks>
>
> I'd be in favor of "unstable" or "stable"
>
> > A single scratchpad block would be nice for small additions
> > while big ones could opt for "c".
>
> aggreed.
>
> <blocks>
> <fop include="true"/>
> ...
>
> <!-- the following blocks are marked unstable and should be
> considered being pre-alpha quality. Their API might change
> without notice -->
> <myteststuff include="false" unstable="true"/>
> <scratchpad include="false" unstable="true"/>
> </blocks>
>
> Ok?
Please, don't use unstable="true" or unstable="false", what about
status="stable" and status="unstable". This is interpreted in a stylesheet
anyway, so please make it more readable for a casual user.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: scratchpad blocks
Posted by Torsten Curdt <tc...@dff.st>.
> > So we could:
> >
> > 1) leave everything like it is :-(
> > 2) have another blocks directory under scratchpad
> > 3) have a single blocks directory and mark and exclude scratchpad stuff
>
> 4) have a scratchpad directory in every block that needs it.
>
> I'm in favour of 3)
excellent - same here :-)
> We could have a new block "scrachpad-block" (a), append "-scratch" to
> the name e.g. "new-stuff-scratch-block" (b), or just add a comment in
> modules.xml saying it is "pre-alpha quality" (c). Either one is
> fine.
<blocks>
<fop include="true"/>
<myteststuff include="false"
scratch="true"
quality="pre-alpha"
unstable="true"
stable="false"
/>
</blocks>
I'd be in favor of "unstable" or "stable"
> A single scratchpad block would be nice for small additions
> while big ones could opt for "c".
aggreed.
<blocks>
<fop include="true"/>
...
<!-- the following blocks are marked unstable and should be
considered being pre-alpha quality. Their API might change
without notice -->
<myteststuff include="false" unstable="true"/>
<scratchpad include="false" unstable="true"/>
</blocks>
Ok?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: scratchpad blocks
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 28.Oct.2002 -- 04:29 PM, Torsten Curdt wrote:
> What about having blocks inside the scratchpad? I just wanted to package the
> precept stuff but it should not go into the maintrunk. so...
>
> I think scratchpad blocks would unify the pattern of creating new stuff... it
> also would be a piece of cake to move things out of the scratchpad then.
>
> On the other hand we could also just create blocks and mark them appropriatly
> and exclude them from the standard build.
>
> So we could:
>
> 1) leave everything like it is :-(
> 2) have another blocks directory under scratchpad
> 3) have a single blocks directory and mark and exclude scratchpad stuff
4) have a scratchpad directory in every block that needs it.
I'm in favour of 3)
We could have a new block "scrachpad-block" (a), append "-scratch" to
the name e.g. "new-stuff-scratch-block" (b), or just add a comment in
modules.xml saying it is "pre-alpha quality" (c). Either one is
fine. A single scratchpad block would be nice for small additions
while big ones could opt for "c".
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org