You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Diana Shannon <sh...@apache.org> on 2002/11/20 19:15:08 UTC
build times
Having worked with a Forrest setup for Cocoon, I was wondering how we
can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1) 30
minutes to build the docs statically. Removing the pdf links (which
prevents pdf generation) still took 24 minutes. I realize build times
are somewhat irrelevant for bots, but, I fear committers won't preview
their doc changes if build times are so long.
Is this all because of the Cocoon command line? Do we have any options?
Or have I overlooked some important configuration detail (e.g.
cocoon.xconf). Or perhaps a problem with my setup.
Thanks.
Diana
Re: build times
Posted by David Crossley <cr...@indexgeo.com.au>.
Diana Shannon wrote:
> Having worked with a Forrest setup for Cocoon, I was wondering how we
> can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1) 30
> minutes to build the docs statically. Removing the pdf links (which
> prevents pdf generation) still took 24 minutes. I realize build times
> are somewhat irrelevant for bots, but, I fear committers won't preview
> their doc changes if build times are so long.
For me (Linux, Java-1.3.1) using your ./build.sh site-F took
12 minutes and lower loglevel from INFO to ERROR shaves only 1 minute.
--David
> Is this all because of the Cocoon command line? Do we have any options?
> Or have I overlooked some important configuration detail (e.g.
> cocoon.xconf). Or perhaps a problem with my setup.
>
> Thanks.
>
> Diana
Re: build times
Posted by Tony Collen <tc...@hist.umn.edu>.
Markus Vaterlaus wrote:
> 20.11.2002 21:56 Uhr +0100, Nicola Ken Barozzi wrote:
>
>>> I think, you are right, about your fears about commiters avoiding to
>>> check their work twice before commiting because of the lenghty
>>> buildtimes. For myself (and not beeing a commiter), that's why I
>>> wanted to set up forrest as a webapp. If I change something in a
>>> xdoc-file, I want to check it just afterwards and not after 10 minutes.
>>
>>
>> With latest Forrest and 0.2 too, just do:
>>
>> forrest run
>>
>> and point the browser to http://localhost:8888/
>>
>> the webapp is automatically generated in ./build/webapp and an
>> embedded Jetty server is used.
>>
>> Less hassle, more speed! :-D
>
>
> Hello Nicola, hi list,
>
> this is really a nice one! Thanks a lot!
"me too!" :)
Tony
>
> Markus
Re: build times
Posted by Markus Vaterlaus <mv...@mus.ch>.
20.11.2002 21:56 Uhr +0100, Nicola Ken Barozzi wrote:
>>I think, you are right, about your fears about commiters avoiding
>>to check their work twice before commiting because of the lenghty
>>buildtimes. For myself (and not beeing a commiter), that's why I
>>wanted to set up forrest as a webapp. If I change something in a
>>xdoc-file, I want to check it just afterwards and not after 10
>>minutes.
>
>With latest Forrest and 0.2 too, just do:
>
> forrest run
>
>and point the browser to http://localhost:8888/
>
>the webapp is automatically generated in ./build/webapp and an
>embedded Jetty server is used.
>
>Less hassle, more speed! :-D
Hello Nicola, hi list,
this is really a nice one! Thanks a lot!
Markus
>--
>Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
Re: build times
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Markus Vaterlaus wrote:
> I think, you are right, about your fears about commiters avoiding to
> check their work twice before commiting because of the lenghty
> buildtimes. For myself (and not beeing a commiter), that's why I wanted
> to set up forrest as a webapp. If I change something in a xdoc-file, I
> want to check it just afterwards and not after 10 minutes.
With latest Forrest and 0.2 too, just do:
forrest run
and point the browser to http://localhost:8888/
the webapp is automatically generated in ./build/webapp and an embedded
Jetty server is used.
Less hassle, more speed! :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Editing sitemap kills webapp (Re: build times)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Nov 21, 2002 at 06:08:11AM -0500, Diana Shannon wrote:
>
> On Wednesday, November 20, 2002, at 03:49 PM, Markus Vaterlaus wrote:
>
> >I think, you are right, about your fears about commiters avoiding to
> >check their work twice before commiting because of the lenghty
> >buildtimes. For myself (and not beeing a commiter), that's why I wanted
> >to set up forrest as a webapp. If I change something in a xdoc-file, I
> >want to check it just afterwards and not after 10 minutes.
>
> I realize that building a webapp, with or without the embedded Jetty
> option, is a promising approach. However, I had trouble with sitemap
> reloading when I tried a webapp-F build for Cocoon.
Yes, it's a Cocoon bug which has since been fixed.
Any volunteers for updating Cocoon? :) Involves testing if things still
work afterwards..
--Jeff
> No time to troubleshoot. I have done this without problems in the past
> with other Forrest-based projects.
>
> Have any other Cocooners tried the Cocoon trial run and made a workable
> webapp (where you could successfully edit the sitemap)?
>
> I'll try Ken's suggestion asap.
>
> Diana
>
Re: build times
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, November 20, 2002, at 03:49 PM, Markus Vaterlaus wrote:
> I think, you are right, about your fears about commiters avoiding to
> check their work twice before commiting because of the lenghty
> buildtimes. For myself (and not beeing a commiter), that's why I wanted
> to set up forrest as a webapp. If I change something in a xdoc-file, I
> want to check it just afterwards and not after 10 minutes.
I realize that building a webapp, with or without the embedded Jetty
option, is a promising approach. However, I had trouble with sitemap
reloading when I tried a webapp-F build for Cocoon. No time to
troubleshoot. I have done this without problems in the past with other
Forrest-based projects.
Have any other Cocooners tried the Cocoon trial run and made a workable
webapp (where you could successfully edit the sitemap)?
I'll try Ken's suggestion asap.
Diana
Re: build times
Posted by Markus Vaterlaus <mv...@mus.ch>.
>Having worked with a Forrest setup for Cocoon, I was wondering how
>we can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1)
>30 minutes to build the docs statically. Removing the pdf links
>(which prevents pdf generation) still took 24 minutes. I realize
>build times are somewhat irrelevant for bots, but, I fear committers
>won't preview their doc changes if build times are so long.
>
>Is this all because of the Cocoon command line? Do we have any
>options? Or have I overlooked some important configuration detail
>(e.g. cocoon.xconf). Or perhaps a problem with my setup.
>
>Thanks.
>
>Diana
Hi Diana, hi list,
out of interest, I tried a to run a build of docs from the command
line (./build.sh docs) within forrest-xml and with the original
xslt-files provided by forrest. At the end, the script printed out
the following information:
>site:
>
>BUILD SUCCESSFUL
>Total time: 9 minutes 9 seconds
>
>docs:
>
>BUILD SUCCESSFUL
>Total time: 9 minutes 25 seconds
My configuration: eMac 700 MHz/640MB, OS X (Jaguar), Java 1.3.1
From my experience gained with exploring cocoon during the past
months I can tell, that all webapps running on my eMac aren't pretty
fast, compared to my old Linux box (366MHz, ~600 MB RAM). However out
of lazyness I rather stick with my Mac, than to use my LINUX box.
I think, you are right, about your fears about commiters avoiding to
check their work twice before commiting because of the lenghty
buildtimes. For myself (and not beeing a commiter), that's why I
wanted to set up forrest as a webapp. If I change something in a
xdoc-file, I want to check it just afterwards and not after 10
minutes.
Markus
Re: build times
Posted by Bernhard Huber <be...@a1.net>.
hi,
just another idea decreate turn around time for writing documentation
1. write the docs using your favourite html-editor,
i tried using netscape html editor
just be aware of following rules:
h1, h2, h3, h4 will become s1, s2, s3, s4 tags,
use a div tag to mark the content of a h1/s1, h2/s2, ... tags.
thus write
<h1>S1Title</h1>
<div>
<p>bla, bla...</p>
<h2>S2Title</h2>
<div>
<p>bla, bla...</p>
</div>
</div>
2. save your html file in an import dir
3. use sitemap definition snippet to check your html docs:
<!-- display an edited html document
-->
<map:pipeline>
<map:match pattern="imports/**.html">
<map:generate type="html" src="imports/{1}.html"/>
<map:transform src="stylesheets/xhtml2document.xsl" label="content"/>
<map:transform src="stylesheets/document2html.xsl"/>
<map:serialize type="html"/>
</map:match>
</map:pipeline>
Use, or adopt the xhtml2document.xsl snippet
<xsl:template match="h1">
<s1>
<xsl:attribute name="title"><xsl:value-of
select="."/></xsl:attribute>
<xsl:apply-templates select="following-sibling::div[1]"/>
</s1>
</xsl:template>
4. If your are happy with the docs, move it to its dest dir,
converting it to xml, that's still on my to-do list....
i know this is not a replacement for a xml editor, but maybe i you
prefer using an html-editor....
any comments?
bye bernhard
Diana Shannon wrote:
> Having worked with a Forrest setup for Cocoon, I was wondering how we
> can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1) 30
> minutes to build the docs statically. Removing the pdf links (which
> prevents pdf generation) still took 24 minutes. I realize build times
> are somewhat irrelevant for bots, but, I fear committers won't preview
> their doc changes if build times are so long.
>
> Is this all because of the Cocoon command line? Do we have any options?
> Or have I overlooked some important configuration detail (e.g.
> cocoon.xconf). Or perhaps a problem with my setup.
>
> Thanks.
>
> Diana
>
Re: build times
Posted by Jeff Turner <je...@apache.org>.
On Wed, Nov 20, 2002 at 10:18:58PM +0100, Bernhard Huber wrote:
> Hi,
>
> Diana Shannon wrote:
> >Having worked with a Forrest setup for Cocoon, I was wondering how we
> >can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1) 30
> >minutes to build the docs statically. Removing the pdf links (which
> >prevents pdf generation) still took 24 minutes. I realize build times
> >are somewhat irrelevant for bots, but, I fear committers won't preview
> >their doc changes if build times are so long.
> >
> >Is this all because of the Cocoon command line? Do we have any options?
> >Or have I overlooked some important configuration detail (e.g.
> >cocoon.xconf). Or perhaps a problem with my setup.
> >
>
> The poor performance you observed might be caused
> by the CommandlineInterface of Cocoon.
> For each document the CLI of Cocoon invokes
> the Cocoon engine 3 time:
> 1. Get the content type of a document, directing
> the content of the document to NullOutputStream
> 2. Get the content of a document
> 3. Get the outbound links of a document
>
> I submitted an Ant version of Cocoon into Cocoon's scratchpad
> area. It skips step 1, as I measured it taks only half of
> the time compared to the CLI version.
> You might want to give it a try, i managed to
> generate the Cocoon documentation successfully,
> but i didn't applied it to the forrest docs, yet.
Sounds very cool.
One thing in the readme:
Processing Cocoon options
-------------------------
targets - comma, space, or semicolon seperated list of target URIs, eg. /index.html,
mandatory
Forrest uses a crawler, not a static list of URIs.. wouldn't this be a problem?
--Jeff
> regards bernhard
>
Re: build times
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, November 20, 2002, at 04:18 PM, Bernhard Huber wrote:
> I submitted an Ant version of Cocoon into Cocoon's scratchpad
> area. It skips step 1, as I measured it taks only half of
> the time compared to the CLI version.
> You might want to give it a try, i managed to
> generate the Cocoon documentation successfully,
> but i didn't applied it to the forrest docs, yet.
Cool, Bernhard. I'll give it a shot.
Thanks.
Diana
Re: build times
Posted by Bernhard Huber <be...@a1.net>.
Hi,
Diana Shannon wrote:
> Having worked with a Forrest setup for Cocoon, I was wondering how we
> can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1) 30
> minutes to build the docs statically. Removing the pdf links (which
> prevents pdf generation) still took 24 minutes. I realize build times
> are somewhat irrelevant for bots, but, I fear committers won't preview
> their doc changes if build times are so long.
>
> Is this all because of the Cocoon command line? Do we have any options?
> Or have I overlooked some important configuration detail (e.g.
> cocoon.xconf). Or perhaps a problem with my setup.
>
The poor performance you observed might be caused
by the CommandlineInterface of Cocoon.
For each document the CLI of Cocoon invokes
the Cocoon engine 3 time:
1. Get the content type of a document, directing
the content of the document to NullOutputStream
2. Get the content of a document
3. Get the outbound links of a document
I submitted an Ant version of Cocoon into Cocoon's scratchpad
area. It skips step 1, as I measured it taks only half of
the time compared to the CLI version.
You might want to give it a try, i managed to
generate the Cocoon documentation successfully,
but i didn't applied it to the forrest docs, yet.
regards bernhard
Re: build times
Posted by Tony Collen <tc...@hist.umn.edu>.
On Wed, 20 Nov 2002, Diana Shannon wrote:
> Having worked with a Forrest setup for Cocoon, I was wondering how we
> can decrease the build time. It took me (on OSX 10.1 JVM 1.3.1) 30
> minutes to build the docs statically. Removing the pdf links (which
> prevents pdf generation) still took 24 minutes. I realize build times
> are somewhat irrelevant for bots, but, I fear committers won't preview
> their doc changes if build times are so long.
>
> Is this all because of the Cocoon command line? Do we have any options?
> Or have I overlooked some important configuration detail (e.g.
> cocoon.xconf). Or perhaps a problem with my setup.
Sounds like a system problem. I tried running C2 on my 300mhz ibook
running OS X and it was unbearably slow. I don't think Java on OS X is as
fast as it should be. You could also try upgrading to 10.2 (and 10.2.2
for that matter) and see if things are helped at all.
Tony
Tony Collen -- tc@socsci.umn.edu
College of Liberal Arts University of Minnesota, Minneapolis, West Bank