Thorsten Scherler wrote: > Thorsten Scherler wrote: > > David Crossley wrote: > ... > > > Drat, i spent so much effort and thought that i had > > > a robust solution whereby they didn't need one. > > > > > > Obviously my tests were not thorough. > > > > > > I revert ASAP. > > > > Is there not a way to have: > > > > We need to find a way that if that file is not in the project the > > > > default is used and no error is caused. > > As far as I understand it (no time to test ATM) the following is causing > it: > > > Modified: > > forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat > > URL: > > http://svn.apache.org/viewvc/forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat?rev=632740&r1=632739&r2=632740&view=diff > > ============================================================================== > > --- forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat > > (original) > > +++ forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat > > Sun Mar 2 03:22:23 2008 > > @@ -52,6 +52,8 @@ > > <!-- Sets of symbols. e.g. for string replacements --> > > <public publicId="-//Apache Forrest//ENTITIES Symbols Core v1.0//EN" > > uri="entity/symbols-core-v10.ent"/> > > + <public publicId="-//Apache Forrest//ENTITIES Symbols Project > > v1.0//EN" > > + uri="entity/symbols-project-v10.ent"/> > > <!-- Various other resources --> > > <public publicId="-//Apache Forrest//ENTITIES Skin Configuration > > common plugins V0.7-1//EN" > > uri="entity/skinconf-common-plugins-07-1.xml"/> > > Where the entity/symbols-project-v10.ent will always be resolved > relative to the project (and not to the above file).
No. What the above means is that i configured the core to have a project symbols file. If they over-ride that in their project's xml catalog they can supply their own file. > Makes me think > whether "cocoon://entity/symbols-project-v10.ent" would not work? The catalog system above should work properly. Not sure if our entity resolver would understand the "cocoon:" protocol. Also the xml catalogs could not then be used in other tools such as xml editors. Your idea might work instead of using the resolver to locate those entities in the declaration of the main sitemaps: main/webapp/sitemap.xmap whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/internal.xmap Another solution would be to put an empty symbols-project-v10.ent file directly at the "main/webapp" directory. When the catalog resolver cannot find a particular resource, then the default place to look is alongside the file that tried to include this resource, e.g. main/webapp/sitemap.xmap However that is not an elegant solution. Anyway, i will revert now and investigate this FOR-1071. > > Your solution is a very nice demonstration how to use entities for this > > common problem. It would be a shame to not find the last piece of the > > puzzle. > > > > I need to have a look again on your commits. Yes it is nice. We should have made more use of the xml framework ages ago. -David
