Leszek Gawron skrev:
Daniel Fagerstrom wrote:
To use the current trunk you start with the cocoon-webapp.
$ cd cocoon-webapp
$ mvn war:inplace jetty6:run
Then you can point your browser at http://localhost:8888/cocoon-webapp/.
I get this:
Message: No default type exists for 'map:transform' at
file:/C:/dev/apache-projects/cocoon-trunk/cocoon-webapp/src/main/webapp/sitemap.xmap:60:62
I got the same problem. It disappear if you add type="xslt" and other
sitemap component selectors for all sitemap rules that use default
selectors. There seem to be some bug in the default type mechanism in
the Spring adapter. The strange thing is that it seem to work while not
adding any block configuration snippets.
Looking further it works if I add default types to the generators and
files elements in cocoon-xforms.xconf. Now it instead can't find the
type jx in http://localhost:8888/cocoon-webapp/samples/blocks/forms/
despite that I have cocoon-template.xconf in WEB-INF/sitemap-additions/
and that the *.xconf in that directory are included in the main sitemap.
It didn't help to rename and move the configuration file to xconf
either. If I added the jx generator configuration directly to the forms
sample sitemap it worked however. Seem like components are not
inhereited properly to sub sitemaps.
I continued to look at the forms samples and they generally give a NPE
while trying to call a flow script. If components aren't properly
inherited to subsitemaps as I guessed above, this behavior is expected,
so I didn't tried to understand it further.
So the problems this far seem to be that default types not are handled
in a back compatible ways for component includes and that components are
not inherited properly to subsitemaps.
Hopefully Carsten have an idea about what is going on.
but I will have to double check if I have updated my working copy.
After having checked that the core actually can serve the start page,
it is time to start adding blocks. This is done by adding the blocks
that you want to the dependencies in the pom.xml of cocoon-webapp.
To actually get some result from this you have to copy the content of
src/main/resources/WEB-INF to the src/main/webapp/WEB-INF of
cocoon-webapp. Now you have the needed configuration files as well.
Last step is to have some samples to look at. Copy
src/main/resources/samples from the appropriate samples project to
cocoon-webapp/src/main/webapp/samples/blocks/<block-name>, and point
your browser to the samples.
It's not the copying of files that bugs me. Does anyone have a solution
how to get rid of those files if I do not want them?
If we have e.g. an Ant task that copy them we could have one that
deletes them as well.
How do I know
during commit which files are just copied over from other directories
and should not be commited.
SVN ignore.
How do we deal with a total mess that war:inplace leaves in src/ directory?
Don't know, but the mess is only in WEB-INF/lib AFAIK, so I guess it
would be enough to delete the jars in that directory.
/Daniel
