Ferdinand Soethe wrote:
Well I basically discovered that checksums-uri in cli.xconf is
functional and works though I haven't figured out why it didn't work
when I tested earlier this year and I haven't had the time to
thoroughly test its function for all kinds of situation.
However I can
Ferdinand Soethe wrote:
Ross Gardler wrote:
[OT - but related] This is perfect for the Google Sitemap plugin that
has recently been contributed to the whiteboard. Are there any docs on this?
No. Haven't gotten around to test this a bit more so there is really
not much to document. Feel
Ross Gardler wrote:
I see your point and agree with the theory. So will it work in practice?
The dynamic part should work already as long as the components we use
are all support caching.
As far as persistant caching is concerned we'll need to address this
question to Cocoon devs to find out
Ferdinand Soethe wrote:
Ross Gardler wrote:
I see your point and agree with the theory. So will it work in practice?
The dynamic part should work already as long as the components we use
are all support caching.
Yes, it does. It is only the static generation that is an issue...
As far
Ross Gardler wrote:
[OT - but related] This is perfect for the Google Sitemap plugin that
has recently been contributed to the whiteboard. Are there any docs on this?
No. Haven't gotten around to test this a bit more so there is really
not much to document. Feel free to ask if you have
Ross Gardler wrote:
Ferdinand Soethe wrote:
However I can already state that this is not going to reduce our build
time because of the way checksums works:
- Create or update a checksum for each document each time it is build
- Next time compare that checksum to the checksum for the newly
Ross Gardler wrote:
We can drastically improve things by creating the new config we need to
support multiple sites. This way each of the docs sets (0.6, 0.7,
0.8-dev), each of the plugin docs, the project information, the users
docs, the developer docs etc. could be made to be separate
What are the best ways of
approaching it? (avoiding building unchanged document is the obvious first
step I guess)
Well yes, but that issue is complex. Evidently
Ferdinand talked with Cocoon people at ApacheCon
and might now have some answers.
Ferdinand, I'd also like to know what you
Ferdinand Soethe wrote:
Ross Gardler wrote:
We can drastically improve things by creating the new config we need to
support multiple sites. This way each of the docs sets (0.6, 0.7,
0.8-dev), each of the plugin docs, the project information, the users
docs, the developer docs etc. could be
Ferdinand Soethe wrote:
- The current size is not big and I like the fact that our own docs
show us how Forrest performs on sites with more pages.
So if we find Forrest to be slow on our own docs-site, lets address the
performance problem.
Yes, this is of course true. You will see
Tim Williams wrote:
What are the best ways of
approaching it? (avoiding building unchanged document is the obvious first
step I guess)
...
One thing to bear in mind is that each time we
enhance the pelt skin, then *all* pages need to
be re-generated even though their content hasn't changed.
Tim and David wrote:
What are the best ways of
approaching it? (avoiding building unchanged document is the obvious first
step I guess)
Well yes, but that issue is complex. Evidently
Ferdinand talked with Cocoon people at ApacheCon
and might now have some answers.
Ferdinand, I'd
Ferdinand Soethe wrote:
Tim and David wrote:
What are the best ways of
approaching it? (avoiding building unchanged document is the obvious first
step I guess)
Well yes, but that issue is complex. Evidently
Ferdinand talked with Cocoon people at ApacheCon
and might now have some answers.
Juan Jose Pablos wrote:
David Crossley wrote:
Would you please explain what you found.
Sure
the cocoon-core.xconf and the forrest-core.xconf differ in content.
Ah, i see. Of course we can all help to synchronise
those configurations. Step 9 of the README.
What I did was to add a
|
| In particular, a good way of getting a handle on where Forrest *may*
| head in the next few releases would be to address
| http://issues.apache.org/jira/browse/FOR-618 Create issues for items
| discussed at Apachecon
|
| Ross
Thanks, I will take a look at this.
Gav...
--
No virus
On Tuesday 09 August 2005 4:56 pm, CFAS Webmaster wrote:
*Please*? ;) I filled my disk twice before I did a ln -s /dev/null
${..}/logs/core.log
Yeah, I had a log of 3.6G lying around in the build dir, and I was wondering
why my backups were suddenly taking _so_ long...
*dives into Cocoon
Thorsten Scherler wrote:
On Tue, 2005-08-09 at 10:23 +0200, Juan Jose Pablos wrote:
Diwaker Gupta wrote:
As Forrest grows and becomes more complex, we really have to watch out for the
build times, and think of ways to reduce the build time. I was doing a build
today of site-author, and it
.
|
| We cannot just upgrade our version of Cocoon
| trunk and expect everything to be the same.
| One of us needs to investigate the Cocoon changes.
|
| -David
I don't know the full ins and outs of these Apache Projects,
but shouldn't there be maybe people dedicated to bridging
the gaps
Gav wrote:
.
|
| We cannot just upgrade our version of Cocoon
| trunk and expect everything to be the same.
| One of us needs to investigate the Cocoon changes.
|
| -David
I don't know the full ins and outs of these Apache Projects,
but shouldn't there be maybe people dedicated to
Gav wrote:
.
|
| We cannot just upgrade our version of Cocoon
| trunk and expect everything to be the same.
| One of us needs to investigate the Cocoon changes.
|
| -David
I don't know the full ins and outs of these Apache Projects,
but shouldn't there be maybe people dedicated to
- Original Message -
From: Juan Jose Pablos [EMAIL PROTECTED]
| you need to give time to people to work on issues
| we do not have dedicated people. We have voluters :-)
I realise this and nearly never posted because of it. This place
has such a friendly atmosphere and it is a case
Gav wrote:
- Original Message -
From: Juan Jose Pablos [EMAIL PROTECTED]
| you need to give time to people to work on issues
| we do not have dedicated people. We have voluters :-)
I realise this and nearly never posted because of it. This place
has such a friendly atmosphere
- Original Message -
From: Ross Gardler [EMAIL PROTECTED]
| That is one of the very important roles of committers within Apache. We
| should be ensuring that we do not duplicate effort between projects and
| therefore we should, as you say, have people in both projects.
|
| You may be
Gav wrote:
- Original Message -
From: Ross Gardler [EMAIL PROTECTED]
...
Keep it up I will, although volunteers can work on any aspect of the
project,
those that have turned into committers have done so by finding a niche area
to concentrate on, this is good for the benefit of
Juan Jose Pablos wrote:
By the way, I found the problem with the performance, I will commit
later today...
Would you please explain what you found.
I see that the build time for our site-author docs
has dropped from 32 minutes to 19 minutes. However
that is still a long way from the 7
Ross Gardler wrote:
You may be interested to know that many of the devs on this list are
also subscribed to the Cocoon lists (and other related Apache
projects, such as Lenya). Some are just watching, some are active.
Ping!
I have no much time to write here. I try to keep an eye on this
Diwaker Gupta wrote:
As Forrest grows and becomes more complex, we really have to watch out for the
build times, and think of ways to reduce the build time. I was doing a build
today of site-author, and it took ** 35 minutes **
Now I might not be running the most powerful machine out there,
Ross Gardler wrote:
Diwaker Gupta wrote:
As Forrest grows and becomes more complex, we really have to watch out
for the build times, and think of ways to reduce the build time. I was
doing a build today of site-author, and it took ** 35 minutes **
One more thing with respect to this...
We
On Tue, 2005-08-09 at 10:23 +0200, Juan Jose Pablos wrote:
Diwaker Gupta wrote:
As Forrest grows and becomes more complex, we really have to watch out for
the
build times, and think of ways to reduce the build time. I was doing a
build
today of site-author, and it took ** 35 minutes
*Please*? ;) I filled my disk twice before I did a ln -s /dev/null
${..}/logs/core.log
My site that takes v0.7 13 minutes to build took 0.8 84 mins. :O Of
course I had to disable the Gallery plugin so that reduced the tasks
somewhat from what 0.7 was doing.
I noticed that each file was
Thorsten Scherler wrote:
Juan Jose Pablos wrote:
I notice as well that the core.log goes huge, this is from the freshsite:
[EMAIL PROTECTED]:/var/tmp/fs/build/webapp/WEB-INF/logs$ du -sh core.log
123Mcore.log
Yes, I think that it was deployed with DEBUG on.
[ snip ]
We have
On Tuesday 09 August 2005 4:56 pm, CFAS Webmaster wrote:
*Please*? ;) I filled my disk twice before I did a ln -s /dev/null
${..}/logs/core.log
Yeah, I had a log of 3.6G lying around in the build dir, and I was wondering
why my backups were suddenly taking _so_ long...
*dives into Cocoon
32 matches
Mail list logo
