cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Using trunk
Date Sat, 25 Feb 2006 11:03:10 GMT
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

Mime
View raw message