the details:
Upayavira wrote:
I believe this (<uri>) is now fixed in CVS. <uris> is a new feature that allows you to process groups of uris, having independant options with each group, e.g. one that follows links, and one that doesn't. You can also describe a link with name="xxx" and then do cocoon cli -xconf cli.xconf -n xxx (I think it's -n) which will only process URIs in your <uris name="xxx"> set.
I think I've updated the docs in CVS, so if you're using CVS cocoon, but looking at the online docs, you'll not see these doc changes.
all right; so I thought I start from scratch:
(1) I got the most recent cvs version from cocoon: 2.1.3-dev;
(2) installed it with jetty and added my webapp "cocoon-day"
(3) it works in "normal" cocoon mode fine as ever.
(4) I tried to fix the things you mentioned, see below:
Can you say more about what you don't understand? If you don't understand it, maybe others don't and thus we need to improve the docs.(2) I also tried to use only command line options, however; I hardly understand what the uri concept and parameters...?!
there are so many confusing things; I just know wget for example: I use an URL there, and it gets the files; recursively or not; I assume similar functionality from cocoon: but there is:
<!--+
| Specifies a user agent string to the sitemap when
| generating the site.
+-->
<!--
<user-agent>xxx</user-agent>
--> <!--+
| Specifies an accept string to the sitemap when generating
| the site.
+-->
<accept>*/*</accept>what is an "user agent"???
why would I want to send an "accept" string to the sitemap?? what should this mean? I provide an URL later on, so what is this for??
<include pattern="**"/> <exclude pattern="docs/apidocs/**"/>
whats this again? the three things I copied from the cli.xconf simply make no sense for me. again: I provide an URL or more then one URL later on; so what should these "filters" be good for? no idea
then:
<uri type="replace" src-prefix="samples/" src="hello-world/hello.html"
dest="build/dest/hello-world.html"/>
o.k. this is lets say 50% clear to me: but why the separation to src-prefix and src? what does the type really mean (append/insert/replace)? no idea yet.
maybe it would become clearer, when I could try my example which is unfortunately still not running.
Fixed in CVS I believe.(3) I came so far with e.g. the code below the line (and the same result with commanline options), that cocoon cli starts, but with the exceptions:
"Cannot find CatalogManager.properties"
yes, but other problems occur, see below
That's because your Cocoon has the HSQLDB block compiled in. I use the CLI with only minimal blocks compiled, which is advisable.
"Opening database: /usr/java/jakarta-tomcat-5.0.9/webapps/cocoon/WEB-INF/db/cocoondb
HSQLDB server 1.7.1 is running
Use SHUTDOWN to close normally. Use [Ctrl]+[C] to abort abruptly"
o.k. I tried to compile cocoon with "minimal" blocks. the problem here again: no idea which blocks I could leave away. I played around for some time; dependency problems occured... finally after some hours I gave up, because compilation always takes between 5 and 20 minutes (aaaarrg, why is there no binary distribution, how came to this idea???)
finally I decided to simply exclude the hsqldb, and at least this hsqldb matter is not occuring again.
What version of Cocoon are you running?
Are you able to rebuild with less blocks?
see above.
o.k. to the last unsuccessful steps now:
(5) I use the cli.xconf in the cocoon distribution, I only added my url to the file and leave everything else the same
<uri type="replace"
src-prefix="cocoon-day/"
src="index.html"
dest="build/dest/index.html"/>{ (5b) btw. I also tried it with some other config file I used recently, both times the same result: }
(6) ./cocoon.sh cli -x cli.xconf
(7) result is:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at Loader.invokeMain(Unknown Source)
at Loader.run(Unknown Source)
at Loader.main(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionBindingListener
... and so on
I find nothing like a "Binding Listener" in the build.properties, at least *I* did not find it.
So again no more ideas on my side.
What I do not understand is, why not even the cli delivered with cocoon works with the cocoon samples in the default installation (I only removed hsqldb); I believe, that this is really not "optimal". I think the cli is really complex enough and it would be advantageous if at least the delivered example would work...
thank you for further comments...
best regards
alex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
