Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
What does it need to get manual rsync calls working so that 2.2 and
portal docs are available at
http://cocoon.apache.org/2.2/ and
http://cocoon.apache.org/blocks/portal/1.0/
Rsync from where?
From the machine
Reinhard Poetz wrote:
Bertrand Delacretaz wrote:
Reinhard Poetz a ?crit :
...Before replacing the documents in cocoon/trunk/src/documentation,
Upayavira will ensure that all docs that differ from the 2.1 docs will
be saved...
Saved = moved to a directory where they can easily be found
Sylvain Wallez wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Sun Feb 20 23:16:58 2005
New Revision: 154651
URL: http://svn.apache.org/viewcvs?view=revrev=154651
Log:
having the version in the directory names causes problems with the
new build system -
Reinhard Poetz wrote:
David Crossley wrote:
Here is one thing that i cannot grasp yet:
How will the automatically generated Sitemap Component Documentation
(i.e. the old /userdocs/) fit in with these static repositories?
Currently we need to run 'build docs' to prepare them, then do
Upayavira wrote:
David Crossley wrote:
Here is one thing that i cannot grasp yet:
How will the automatically generated Sitemap Component Documentation
(i.e. the old /userdocs/) fit in with these static repositories?
Currently we need to run 'build docs' to prepare them, then do 'forrest
Reinhard Poetz wrote:
Upayavira wrote:
David Crossley wrote:
[snip]
The trouble that i have with the new documentation proposal is that
docs sources are moving to another part of the repository, so how
will 'build docs' be able to access them? I suppose that assumed default
relative
Reinhard Poetz wrote:
Last week Upayavira and I spent some time to overhaul the structure of the
two
document repositories:
- http://brutus.apache.org/docs/build/cocoon-doco-2-2/
- http://brutus.apache.org/docs/build/cocoon-doco-global/
We think that it covers all Cocoon relevant
Tim Larson wrote:
Sylvain Wallez wrote:
The nice thing once all this has been fixed, is that SVN doesn't
consider as being modified a file where expanded keyword have been
replaced by their unexpanded counterpart. You can then use whatever
diffmerge tool you want to sync 2.2 and 2.1,
nafise hassani wrote:
Hi
what's your idea about the comparison that takes
between
orbeon and cocoon in this site:
http://www.orbeon.com/community/cocoon
All that we can do is laugh at the innacuracies of those
who attempt comparison with Cocoon, e.g. the Orbeon fallacies:
quote
Reinhard Poetz wrote:
David Crossley wrote:
There is no point wasting energy on defending Cocoon.
Just get on with making our own ship robust.
I can offer two links:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110683337721591w=2 and
http://wiki.apache.org/cocoon
Andreas Kuckartz wrote:
Look at http://wiki.apache.org/cocoon/CocoonDocumentationSystem and find all
my
requirements. I'm sure that all six options are good enough but as *I* have
to
do it, I'll take the road that's the fastest for *me*.
There was a misunderstanding on my side. I had
Ralph Goers wrote:
Antonio Gallardo wrote:
I tried a full build (without local.*) and it is broken. The error is the
same as was fixed in 2.2:
No that is a different error. The PhP block is gone is 2.2
/home/agallardo/svn/cocoon-2.1/tools/targets/docs-build.xml:56:
Tony Collen wrote:
Ralph Goers wrote:
Antonio Gallardo wrote:
I tried a full build (without local.*) and it is broken. The error is the
same as was fixed in 2.2:
/home/agallardo/svn/cocoon-2.1/tools/targets/docs-build.xml:56:
com.thoughtworks.qdox.parser.ParseException: syntax error
the documentation
differences. If we can just find out what is so different about
the PhpGenerator.java source that makes qdox barf.
--David
David Crossley dijo:
Ralph Goers wrote:
Antonio Gallardo wrote:
I tried a full build (without local.*) and it is broken. The error is
the
same
David Crossley wrote:
Antonio Gallardo wrote:
Hmmm. Then what to do?
David, need we another inter Ocean Pacific Sprint to fix that? ;-)
LOL. As long as you promise not to stay awake all night. :-)
Well it would be best to have this SitemapTask/qdox working
in both trunk
Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Howdy,
I was browsing around the awesome www.jdocs.org web site and was pleased
to find cocoon there, but your version number is completely bogus.
Cocoon 1.2.5.1 never even existed, I think you mean 2.1.5, which is the
latest released
Reinhard Poetz wrote:
Thank you. But as you say, it depends if it is allowed that either a webapp
or a mail server is allowed to do a commit. If yes, we have many options.
With the current situation, that is a no.
Evidently there are solutions on the way.
Spurts of discussion happen on
Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
Yep. I hope that I can convince at least one of them to help me. Actually I
need some Java code ;-) So here I ask officially: Who volunteers to write
the Java code that communicates with the SVN repository (read and commit
Stefano Mazzocchi wrote:
Bertrand Delacretaz wrote:
Reinhard Poetz a ?crit :
At http://wiki.apache.org/cocoon/CocoonDocumentationSystem I propose
the architecture of a new extensible documentation system...
Thanks Reinhard - to me this looks really good, and the fact that you're
Reinhard Poetz wrote:
At http://wiki.apache.org/cocoon/CocoonDocumentationSystem I propose the
architecture of a new extensible documentation system.
Thanks, a brilliant step.
My first goal is
reusing existing functionality (SVN, Forrest, static web pages). Writing
the missing pieces
Antonio Gallardo wrote:
I think I got the source of the problem: some transformers has bad
written javadocs that don't use the agreed format. Please do an SVN update
to see if it changes in your case too. Now I am getting a diferent one
after adding a new tag in the Includetranformer:
Antonio Gallardo wrote:
Hi David:
4:00 a.m. here! :-(
I guess I found and fixed the source error. (Am I telling the same again?
- lol.).
:-)
There you go, doing one of your super-human efforts again.
Thanks, that is an excellent step forward.
--David
Antonio Gallardo wrote:
Hi David:
4:00 a.m. here! :-(
I guess I found and fixed the source error. (Am I telling the same again?
- lol.).
I did some System.out of the process (included in the commit). Made a
workaround hack and I will commit. The hack works. :-D
No difference for me.
Geoff Howard wrote:
David Crossley wrote:
Antonio Gallardo wrote:
Can you post where the problem is showed to you trying a full build? I am
trying to get an idea if the problem is truly random or just because users
have diferent blocks configurations in local.blocks.properties
+0 for the French list. (i.e. i cannot help).
and i echo Geoff's concerns.
The list should have more than just two Euro-centric moderators.
Perhaps a French-speaking Canadian dev will offer to be another.
--David
Antonio Gallardo wrote:
Workaround: disable doc generation in local.build.properties.
Posible cause:
AFAIK, recently David is in process to integrate a new forrest version in
Cocoon and this could be the problem cause. ;-)
No, not that. In fact, Forrest is now completely separated from the
Geoff Howard wrote:
odd that this is breaking in different places for everyone. Do you
all have different sets of blocks enabled?
I have all blocks enabled.
If not, I'm suspicious of out of memory error or something odd like
that. In that case, any chance that the docs build tasks could
component interface error.
This one is too wierd. I will start a new thread to discuss it.
--David
David Crossley said:
Antonio Gallardo wrote:
Workaround: disable doc generation in local.build.properties.
Antonio Gallardo wrote:
The lastest changes of docs-build.xml (SVN 124702):
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=110523951602586w=2
from:
sitemap-components docDir=${build.context}/xdocs/userdocs
source=${java}/
to:
sitemap-components
Antonio Gallardo wrote:
David Crossley dijo:
It is not the cause, it just enables to bug to manifest.
OK.
Can you post where the problem is showed to you trying a full build? I am
trying to get an idea if the problem is truly random or just because users
have diferent blocks
Ralph Goers wrote:
David Crossley wrote:
I showed that a few messages ago in this thread.
Both Ross and i are doing a full build, javadocs and all,
with no blocks disabled. It breaks in different places
for each of us.
Does it fail for you in BRANCH_2_1_X (before you disabled
The Cocoon SitemapTask in trunk is suddenly throwing a wobbly.
-
...
Building component docs from blocks.
Collecting sitemap components info
BUILD FAILED
/opt/cocoon-trunk/tools/targets/docs-build.xml:55:
Sitemap component org.apache.cocoon.generation.HTMLGenerator
does not
Antonio Gallardo wrote:
Hi:
AFAIK, the methods names should start with a lowercase char. I found some
classes wich methods are Capitalized:
src/java/org/apache/cocoon/components/xpointer/parser/TokenMgrError.java
src/java/org/apache/cocoon/components/xpointer/parser/SimpleCharStream.java
David Crossley wrote:
The build of Cocoon's static docs in trunk is now using
the forrest_06_branch.
Oh, i forgot to mention.
cd /svn/asf/cocoon-trunk
forrest run
http://localhost:/
edit docs on the filesystem and see the effect.
There is one catch. Normally you would edit the xdocs
Carsten Ziegeler wrote:
With the latest changes to the build system in trunk regarding forrest,
the version number of Cocoon is overwritten by a forrest installation.
In my build environment I have set FORREST_HOME to a 0.5 forrest
installation and when building Cocoon, Cocoon uses this 0.5
David Crossley wrote:
Carsten Ziegeler wrote:
With the latest changes to the build system in trunk regarding forrest,
the version number of Cocoon is overwritten by a forrest installation.
In my build environment I have set FORREST_HOME to a 0.5 forrest
installation and when building
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
With the latest changes to the build system in trunk regarding forrest,
the version number of Cocoon is overwritten by a forrest installation.
In my build environment I have set FORREST_HOME to a 0.5 forrest
installation and when building
Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
[snip]
We already do have a separate repository for that (A):
http://svn.apache.org/repos/asf/cocoon/site/
It already contains the sources for project and community stuff
sorry, overlooked this
as well as all
Carsten Ziegeler wrote:
David Crossley wrote:
David Crossley wrote:
Carsten Ziegeler wrote:
With the latest changes to the build system in trunk regarding forrest,
the version number of Cocoon is overwritten by a forrest installation.
In my build environment I have set FORREST_HOME
Carsten Ziegeler wrote:
David Crossley wrote:
Carsten Ziegeler wrote:
If this is the only property that gets overwritten by forrest, then I'm
fine with this.
That would be a good workaround to give us room to breathe. I will not
be able to do it until tomorrow our time.
I think we
David Crossley wrote:
David Crossley wrote:
The build of Cocoon's static docs in trunk is now using
the forrest_06_branch.
Oh, i forgot to mention.
cd /svn/asf/cocoon-trunk
forrest run
http://localhost:/
edit docs on the filesystem and see the effect.
There is one catch
Reinhard Poetz wrote:
If we talk about documentation we usually mean all the documents available
at
http://cocoon.apache.org. I think it's time to look at our documentation in
a more differentiated way.
Currently we have a
- project documentation (who we are, download, ...)
-
and the cocoon-site top-level to both
use forrest-0.6 too.
--David
David Crossley wrote:
David Crossley wrote:
Reinhard Poetz wrote:
[snip]
and set up the sekelton of new ones using Forrest 0.6.
The Cocoon build system needs some work to enable that.
There are issues with clashes of Ant
Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
[snip]
and set up the sekelton of new ones using Forrest 0.6.
The Cocoon build system needs some work to enable that.
There are issues with clashes of Ant target names, e.g. webapp
and variable names, e.g. $version.
Use
Reinhard Poetz wrote:
Some of us started with generating docs out of Java sources (sitemap
components). I have to admit that I have no experience with this process
but I would like to integrate these reference docs into the new
documentation.
There is a rough explanation at
Daniel Fagerstrom wrote:
crossley wrote:
==
--- cocoon/trunk/tools/targets/forrest-build.xml (original)
+++ cocoon/trunk/tools/targets/forrest-build.xml Mon Dec 27 22:59:47
...
+ import
Reinhard Poetz wrote:
I propose to remove the docs in trunk. I don't think they are syncronized
with 2.1 and IMO there is no reasons to have them twice. It's also a chance
to rewrite and restructure our documentation.
Careful. They are *not* synchronised. We will lose edits that people
David Crossley wrote:
Reinhard Poetz wrote:
[snip]
and set up the sekelton of new ones using Forrest 0.6.
The Cocoon build system needs some work to enable that.
There are issues with clashes of Ant target names, e.g. webapp
and variable names, e.g. $version.
Use the forrest_06_branch
Sylvain Wallez wrote:
Team, here's a formal vote about splitting cocoon.xconf.
+1
--David
Marc Portier wrote:
there is more of that around:
e.g. try 'apt-get install forrest' on a debian linux
credits to our own Marcus Crafter:
http://blogs.cocoondev.org/crafterm/archives/002055.html
-marc=
Thanks for reporting that.
Marcus, many thanks for doing that, however it would be
[EMAIL PROTECTED] wrote:
Guys,
Please improve and extend the following text. The intention is provide
people enough information to decide whether Cocoon is the right choice for
their problem/project.
Oh good on you Helma, great idea. I will comment in more detail later.
Where do you see
Carsten Ziegeler wrote:
David Crossley wrote:
That is the trouble - i don't know what is correct.
:)
The file called components-javadoc-sitemaptask-diff.txt
is the difference between the list produced by scanning
javadocs (finding extra clutter, maybe missing some) and the
list
Carsten Ziegeler wrote:
David Crossley wrote:
Okay, i uploaded them to my ASF committer space
www.apache.org ~crossley/review-sitemap-docs/ See the notes
in SVN cocoon-2_1_X/tools/review-sitemap-docs/README.txt
and cocoon-2_1_X/tools/review-sitemap-docs/TODO.txt
Thanks!!
So
Upayavira wrote:
David Crossley wrote:
Okay the initial coordination table is now ready.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
The next task is to review the table to ensure that
all entries have been added for sitemap components.
Are you proposing to update all
Carsten Ziegeler wrote:
David Crossley wrote:
I am working on this in cocoon-2_1_X branch.
In tools/targets/docs-build.xml uncomment the
sitemap-components task at line 56 to also scan the blocks.
Then run 'build javadocs'.
Then run 'build docs'. This will also produce lists
Upayavira wrote:
Tony Collen wrote:
Vadim Gritsenko wrote:
IIUC, all of the above is not relevant for SVN as long as
svn:eol-type property is set... Can somebody confirm?
Perhaps a note about how to set this property in svn would be useful :)
I did think about this when writing, but
Carsten Ziegeler wrote:
David Crossley wrote:
...
which misses src/java/o/a/c/serialization/XMLSerializer.java
perhaps because that extends AbstractTextSerializer.
Ah, ok, that's strange. My understanding was that this should work
and if I'm not mistaken it works for other classes
Vadim Gritsenko wrote:
upayavira wrote:
@@ -31,17 +31,17 @@
section id=whitespace
titleConsistent whitespace/title
p
-Whitespace can cause big problems with CVS. If it is inconsistent,
+Whitespace can cause big problems with SVN. If it is inconsistent,
David Crossley wrote:
Bertrand Delacretaz wrote:
Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
echo $i | sed 's/\//\./g' | sed 's/\.html
Bertrand Delacretaz wrote:
David Crossley a ?crit :
...Using the grep javadocs method does not find any
serializers, actions, matchers, selectors.
Why, can't you grep their base interfaces like:
for i in $(egrep -rl 'SitemapModelComponent|OtherBaseInterface|Other)
?
Oh, i haven't tried
Carsten Ziegeler wrote:
David Crossley wrote:
...Fiddling with the SitemapTask.java i can also
getting a listing.
So i will be able to work out a solution. Thanks.
Hmmm, no joy so far.
Using the grep javadocs method does not find any serializers,
actions, matchers, selectors
Upayavira wrote:
David Crossley wrote:
Bertrand Delacretaz wrote:
David Crossley a ?crit :
...Using the grep javadocs method does not find any
serializers, actions, matchers, selectors.
Why, can't you grep their base interfaces like:
for i in $(egrep -rl 'SitemapModelComponent
Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s). Would that work?
Thanks Geoff. However, command-line tools only
because i need to script it. Sorry, i forgot
to specify that.
--David
Bertrand Delacretaz wrote:
Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
echo $i | sed 's/\//\./g' | sed 's/\.html$//'
done
There's still a
I am trying to create a list of all sitemap
components in the Cocoon core and blocks.
So far i have tried to use 'find and grep'
by looking for well-known filenames,
e.g. *Transformer.java and also searching in
well-known directories, e.g. /transformation/
However, that misses some components and
Micah Dubinko wrote:
Stefan Pietschmann wrote:
The doctype is not set either as Micah already mentioned.
It is set up to serialize a Doctype if it's present in the incoming
stream, but it doesn't read from the sitemap configuration to read
specific values for cases where the stream doesn't have
Torsten Curdt wrote:
...at least in Germany we celebrate the 6th of Dec
with little presents.
Well, I finished my little present for you guys just in
time (about an hour ago). Ladies and gentleman:
...we have auto-compiling javaflow!!
What on earth can we give you as a return gift?
Community
Bertrand Delacretaz wrote:
David Crossley a écrit :
...That is why i was asking if anyone was going
to say: stop, we need to throw away or redesign that
excellent SitemapTask to cope with separate bloack docs
nitpicking
Just one small thing: the name SitemapTask says little about what
Bertrand Delacretaz wrote:
David Crossley a écrit :
Okay the initial coordination table is now ready.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
big big thanks for making this happen, it is an important step I think.
Hope to find time to help here.
You already are.
Maybe
A reminder that Cocoon FirstFriday starts in 9 hours.
http://wiki.apache.org/cocoon/FirstFriday
Luca Morandini wrote:
At a glance I can see that Ant generator from scratchpad is missing
(org.apache.cocoon.ant.AntBuildGenerator).
Thanks Luca, that revealed a flaw in my 'find' script.
I was expecting stuff to be organised in directories
like org/apache/cocoon/.../generation/ etc.
However,
[EMAIL PROTECTED] wrote:
I have made some progress on this task. My first
step is to use UNIX tools find and grep, to estimate
how many component documents and how many components
we already have. I am building the first few columns
of the co-ordination table to list the documents and
related java
Would someone else please update the apidocs
on the website. The memory consumption by
'build javadocs' kills my build (using the
default setting).
--David
Okay the initial coordination table is now ready.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
The next task is to review the table to ensure that
all entries have been added for sitemap components.
--David
Antonio Gallardo wrote:
On Mie, 1 de Diciembre de 2004, 23:07, Antonio Gallardo dijo:
On Mie, 1 de Diciembre de 2004, 17:21, David Crossley dijo:
Would someone else please update the apidocs
on the website. The memory consumption by
'build javadocs' kills my build (using the
default setting
Antonio Gallardo wrote:
Hi David:
The apidocs for cocoon 2.1.6 are now online:
http://cocoon.apache.org/2.1/apidocs/
Thanks for your help. :-D
Well thanks to you for taking up the challenge :-)
--David
Upayavira wrote:
[EMAIL PROTECTED] wrote:
Hi,
This is YOUR big chance of integrating the information in both places and
remove the redundant line from the index page.
Aaaah.
Thanks for that, you've just prodded me into working out what is going
on. The lower case ones come from the
Upayavira wrote:
Have any docs actually been done with this process? I'm curious to find
out more about how what the conversion actually does. (I guess I could
just try it, but then, that would be too easy!)
There are about 30 docs that are generated with this process.
So far i have listed about
David Crossley wrote:
Upayavira wrote:
[EMAIL PROTECTED] wrote:
Hi,
This is YOUR big chance of integrating the information in both places
and
remove the redundant line from the index page.
Aaaah.
Thanks for that, you've just prodded me into working out what is going
on. The lower
I have made some progress on this task. My first
step is to use UNIX tools find and grep, to estimate
how many component documents and how many components
we already have. I am building the first few columns
of the co-ordination table to list the documents and
related java files. Not finished yet.
Hi Vadim, these automated tests that you have
are great. Thanks. However i hear that the
Infrastructure people are moving all services
off nagoya. So these tests might need to
find a new home.
How about asking the Gump people for an account on
brutus ... just ask on [EMAIL PROTECTED]
Vadim Gritsenko wrote:
Geoff Howard wrote:
bash-2.05b$ groups tschlabach
tschlabach apcvs lenya
This should mean you have commit access to lenya. Only one way to be
sure... :)
No, it does not :) Lenya is in SVN
http://svn.apache.org/repos/asf/lenya/
Which does not use unix groups but
Ralph Goers wrote:
David Crossley wrote:
[snip]
People who help are going to need to get their
hands dirty in the xdocs and java code sources anyway.
I believe only committers can check in changes to xdocs and java code.
There are several folks who aren't committers who, I believe, would like
-Original Message-
From: David Crossley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 24 November, 2004 12:52
To: [EMAIL PROTECTED]
Subject: Re: [Proposal] review of sitemap component documentation
Ralph Goers wrote:
David Crossley wrote:
[snip]
People who help are going to need to get
Bertrand Delacretaz wrote:
[EMAIL PROTECTED] a écrit :
...If you do it in xdoc, beware that you will end up the
administrator of the table (integrating commits from
non-committers)...
FYI I volunteer to help maintaining this file based on info provided
by non-commiters, so that David does not
Stefano Mazzocchi wrote:
I think having a 40Kb sitemap for a just a few pipelines scares people
way and makes the learning curve steeper.
here is my proposal for Cocoon 2.2:
1) move the current webapp/sitemap.xmap into webapp/WEB-INF/sitemap.xmap
2) make the sitemaps inherit from that one
I updated the Cocoon website today and then
tried to clean up the instructions on the
Wiki page CocoonWebsiteUpdate. Would another
committer please try to follow thos instructions
--David
Bertrand Delacretaz wrote:
Ralph Goers a écrit :
...Does this mean the list contains all past and present committers?
AFAIK yes, did you spot people missing from the list?
-Bertrand
There is another page at http://cocoon.apache.org/2.1/who.html
Go ahead, add yourself to both.
--David
Ralph Goers wrote:
Bertrand Delacretaz wrote:
Le 25 nov. 04, à 08:18, Ralph Goers a écrit :
...Does this mean the list contains all past and present committers?
AFAIK yes, did you spot people missing from the list?
-Bertrand
Well, yes. Leszek Gawron and myself. This was expected since we were
The current User Guide documentation has one document
for each Sitemap Component, e.g.
http://cocoon.apache.org/2.1/userdocs/generators/file-generator.html
Each main document has a shell with some content
in src/documentation/xdocs/userdocs/*
During the 'build docs' a SitemapTask' is called.
This
Reinhard Poetz wrote:
Go for it!
We also have to consider that we have more independant blocks very soon,
means that we have the goal that each block can be released seperatly
and IMO it should provide its own docs.
This seems to be the simple part. More difficult is providing a complete
Ralph Goers wrote:
In the wiki at http://wiki.apache.org/cocoon/MergingBranches you can see
an example of a sort of working to-do list. If you create a document
along these lines in the wiki with the names of the source files that
need work I promise I will help out in updating at least some of
David Crossley wrote:
Upayavira wrote:
Also, when I did run Forrest, I really had to dig to find the
generated pages, whereas I would have expected them to have been
generated in place, i.e. into the place from which I'd commit them
directly to SVN.
We can change the location of where
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 19 nov. 04, 17:23, [EMAIL PROTECTED] a crit :
On Fri, 19 Nov 2004, Bertrand Delacretaz wrote:
Le 19 nov. 04, 16:05, Upayavira a crit :
...Thus, the site needs to be regenerated with Forrest, which, to
date, I haven't done.
You probably know this
Upayavira wrote:
Ralph Goers wrote:
Upayavira wrote:
Hi,
I've just run Forrest and have uploaded the site to:
http://www.apache.org/~upayavira/site/
Can you take a look, and make sure I've run the Forrest process
correctly?
If this looks okay (I'm aware of a couple of details, e.g. jimi),
I'll
Upayavira wrote:
David Crossley wrote:
I'll do that too, if I can get Forrest to work. Unfortunately the
above link doesn't entirely make sense.
Would you please explain that obscure comment.
Let us all help to fix the instructions then.
Sorry, wasn't trying to be cryptic - I was referring
Upayavira wrote:
I see you've fixed some of these on the wiki. Thanks. Also, the page
refers to a default.properties file. I can't find such a file, nor can I
find any reference to it in Cocoon's build target files. Am I supposed
to use a property to set it, or environment variable, or a
Upayavira wrote:
David Crossley wrote:
Upayavira wrote:
Okay. My request was more to do with have I run Forrest right. I
should have made that more clear.
There are two aspects.
* The person who ran the 'forrest' command
would have seen the Build Successful note.
* Any of us can review
Bertrand Delacretaz wrote:
Le 19 nov. 04, à 19:49, Upayavira a écrit :
http://wiki.apache.org/cocoon/CocoonWebsiteUpdate
...
I'll do that too, if I can get Forrest to work. Unfortunately the
above link doesn't entirely make sense.
FYI I have tried the following, no success at this point. But I
Sylvain Wallez wrote:
Upayavira wrote:
Says:
if (!(d.canRead() d.canWrite())) {
log.error(Directory ' + d + ' is not readable/writable);
throw new IOException(Directory ' + d + ' is not
readable/writable);
}
Hmm. This has been in the CLI since Cocoon 2.0. I've no
501 - 600 of 892 matches
Mail list logo
