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/29 03:04:09 UTC
build system [was: scratchpad blocks]
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: 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