You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2008/03/04 00:21:07 UTC

dependency on project symbols file (Was: svn commit: r632740)

Thorsten Scherler wrote:
> Gav.... wrote:
> > 
> > This may be related to this commit.
> 
> Not sure if exactly to this one, but to one of them.
> 
> > After doing : svn up; cd main; build clean; build
> > Then doing a 'forrest seed-basic' 'forrest run' gives me :-
> > 
> > 17:59:29.984 EVENT  Started org.mortbay.jetty.Server@443226
> > Failed to create InputSource (java.io.FileNotFoundException:
> > D:\web\16degrees\sr
> > c\documentation\resources\schema\symbols-project-v10.ent (The system cannot
> > find
> >  the file specified)):
> > file:/D:/web/16degrees/src/documentation/resources/schema
> > /symbols-project-v10.ent
> > 
> > .. and outputs nothing in the web browser.
> 
> Yeah, I see the same in a custom project. This work introduced a
> dependency to symbols-project-v10.ent which I do not like at all!
> 
> We need to find a way that if that file is not in the project the
> default is used and no error is caused. 

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.

-David

RE: dependency on project symbols file (Was: svn commit: r632740)

Posted by "Gav...." <br...@brightontown.com.au>.

> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Tuesday, 4 March 2008 4:01 PM
> To: dev@forrest.apache.org
> Subject: Re: dependency on project symbols file (Was: svn commit: r632740)
> 
> David Crossley wrote:
> > David Crossley wrote:
> > >
> > > 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.
> >
> > Aha, i found it. When this ability for "project and core symbols"
> > was added in forrest-0.8 version, i declared the project symbols
> > in the xml catalog.xcat file of our seed projects. However i only
> > supplied the actual file of symbols in the "fresh-site" not in
> > the main/template-sites/basic/
> >
> > So if people based their sites on 'forrest seed' then all would
> > be okay. However, if based on 'forrest seed-basic' then not.
> 
> All is okay now. I found a workaround and described its implementation
> in FOR-1071.
> 

Thanks, yes, just copying in the file works fine.

I tend to use 'forrest seed-basic' these days when starting new sites rather
than strip down a nicely populated 'forrest seed'.

Gav...


> -David
> 
> 
> --
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.9 - Release Date: 2/20/2008
> 12:00 AM

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Thorsten Scherler wrote:
> > 
> > Being "just" a warning that will produce lots of mails. That is why I
> > added the note to the upgrading document.
> 
> However the note is misleading. So i will try to improve
> that documentation and link to the FAQs on the topic.

I changed it, as i think that you were describing the wrong thing.
It was actually caused by FOR-1075, and FOR-1071 revealed it.
Also showed the warning message that such users would receive.

Thanks for trying to add the missing piece. I knew yesterday
that i should have explained the warning message in the
"upgrading" doc, but then forgot in the main commit. It is
always easier if the original implementor describes issues.

-David

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2008-03-05 at 09:36 +1100, David Crossley wrote:
> Thorsten Scherler wrote:
> > 
> > Being "just" a warning that will produce lots of mails. That is why I
> > added the note to the upgrading document.
> 
> However the note is misleading. So i will try to improve
> that documentation and link to the FAQs on the topic.

Did you see
http://svn.apache.org/viewvc?rev=633649&view=rev

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> 
> Being "just" a warning that will produce lots of mails. That is why I
> added the note to the upgrading document.

However the note is misleading. So i will try to improve
that documentation and link to the FAQs on the topic.

-David

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-03-05 at 00:55 +1100, David Crossley wrote:
> Thorsten Scherler wrote:
> > David Crossley wrote:
> > > Thorsten Scherler wrote:
> > > > > David Crossley wrote:
> > > > > 
> > > > > All is okay now. I found a workaround and described its implementation
> > > > > in FOR-1071.
> > > > 
> > > > Hmm, meaning we have a dependency on this file which all sites that
> > > > updates to a future 0.9 release need to add to the custom project.
> > > 
> > > No. No-one is required to add any file. Please read the documentation.
> > > I have worked very hard to ensure that.
> > 
> > Well, so why I needed to add the file to my custom project, otherwise I
> > will get: 
> 
> That is just a warning. 

Being "just" a warning that will produce lots of mails. That is why I
added the note to the upgrading document.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2008-03-05 at 00:55 +1100, David Crossley wrote:
> Thorsten Scherler wrote:
...
> You are getting the warning because you have a partially configured
> system based on bug FOR-1075. Either remove the partial configuration
> in src/documentation/resources/schema/catalog.xcat or add the file.

I updated the documentation and added the information about
catalog.xcat.

> ...
> > Did you try on a project where you removed the symbols-project-v10.ent
> > file?
> 
> Of course. I tried everything that i could think of to test.

Thanks very much David, good on ya mate.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley wrote:
> > Thorsten Scherler wrote:
> > > > David Crossley wrote:
> > > > 
> > > > All is okay now. I found a workaround and described its implementation
> > > > in FOR-1071.
> > > 
> > > Hmm, meaning we have a dependency on this file which all sites that
> > > updates to a future 0.9 release need to add to the custom project.
> > 
> > No. No-one is required to add any file. Please read the documentation.
> > I have worked very hard to ensure that.
> 
> Well, so why I needed to add the file to my custom project, otherwise I
> will get: 

That is just a warning. The project still worked properly didn't it.

You are getting the warning because you have a partially configured
system based on bug FOR-1075. Either remove the partial configuration
in src/documentation/resources/schema/catalog.xcat or add the file.
But it is still just a warning. There is the workaround described
in the end of FOR-1071 which automatically handles this case.

> Failed to create InputSource
> (java.io.FileNotFoundException: /home/thorsten/src/sadesi/boja2/trunk/exporter/src/documentation/resources/schema/symbols-project-v10.ent (No such file or directory)): file:/home/thorsten/src/sadesi/boja2/trunk/exporter/src/documentation/resources/schema/symbols-project-v10.ent
> 
> Did you try on a project where you removed the symbols-project-v10.ent
> file?

Of course. I tried everything that i could think of to test.

-David

> Try something like:
> mkdir 1071
> cd 1071/
> forrest seed-basic
> rm symbols-project-v10.ent
> forrest run
> lynx http://localhost:8888/index.html
> 
> > If a project wants to take advantage of this feature to over-ride
> > some core settings, then yes of course they do need to add a file
> > if they don't already have it.

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-03-05 at 00:08 +1100, David Crossley wrote:
> Thorsten Scherler wrote:
> > David Crossley wrote:
> > > David Crossley wrote:
> > > > David Crossley wrote:
> > > > > 
> > > > > 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.
> > > > 
> > > > Aha, i found it. When this ability for "project and core symbols"
> > > > was added in forrest-0.8 version, i declared the project symbols
> > > > in the xml catalog.xcat file of our seed projects. However i only
> > > > supplied the actual file of symbols in the "fresh-site" not in
> > > > the main/template-sites/basic/
> > > > 
> > > > So if people based their sites on 'forrest seed' then all would
> > > > be okay. However, if based on 'forrest seed-basic' then not.
> > > 
> > > All is okay now. I found a workaround and described its implementation
> > > in FOR-1071.
> > 
> > Hmm, meaning we have a dependency on this file which all sites that
> > updates to a future 0.9 release need to add to the custom project.
> 
> No. No-one is required to add any file. Please read the documentation.
> I have worked very hard to ensure that.

Well, so why I needed to add the file to my custom project, otherwise I
will get: 
Failed to create InputSource
(java.io.FileNotFoundException: /home/thorsten/src/sadesi/boja2/trunk/exporter/src/documentation/resources/schema/symbols-project-v10.ent (No such file or directory)): file:/home/thorsten/src/sadesi/boja2/trunk/exporter/src/documentation/resources/schema/symbols-project-v10.ent

Did you try on a project where you removed the symbols-project-v10.ent
file?

Try something like:
mkdir 1071
cd 1071/
forrest seed-basic
rm symbols-project-v10.ent
forrest run
lynx http://localhost:8888/index.html

salu2

> 
> If a project wants to take advantage of this feature to over-ride
> some core settings, then yes of course they do need to add a file
> if they don't already have it.



> 
> -David
> 
> > I am not too excited about this but have no time to follow up on it and
> > the work is too valuable to loose it. I will add a note to the update
> > document.
> > 
> > salu2
> > -- 
> > Thorsten Scherler                                 thorsten.at.apache.org
> > Open Source Java                      consulting, training and solutions
> > 
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley wrote:
> > David Crossley wrote:
> > > David Crossley wrote:
> > > > 
> > > > 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.
> > > 
> > > Aha, i found it. When this ability for "project and core symbols"
> > > was added in forrest-0.8 version, i declared the project symbols
> > > in the xml catalog.xcat file of our seed projects. However i only
> > > supplied the actual file of symbols in the "fresh-site" not in
> > > the main/template-sites/basic/
> > > 
> > > So if people based their sites on 'forrest seed' then all would
> > > be okay. However, if based on 'forrest seed-basic' then not.
> > 
> > All is okay now. I found a workaround and described its implementation
> > in FOR-1071.
> 
> Hmm, meaning we have a dependency on this file which all sites that
> updates to a future 0.9 release need to add to the custom project.

No. No-one is required to add any file. Please read the documentation.
I have worked very hard to ensure that.

If a project wants to take advantage of this feature to over-ride
some core settings, then yes of course they do need to add a file
if they don't already have it.

-David

> I am not too excited about this but have no time to follow up on it and
> the work is too valuable to loose it. I will add a note to the update
> document.
> 
> salu2
> -- 
> Thorsten Scherler                                 thorsten.at.apache.org
> Open Source Java                      consulting, training and solutions
> 

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Tue, 2008-03-04 at 18:00 +1100, David Crossley wrote:
> David Crossley wrote:
> > David Crossley wrote:
> > > 
> > > 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.
> > 
> > Aha, i found it. When this ability for "project and core symbols"
> > was added in forrest-0.8 version, i declared the project symbols
> > in the xml catalog.xcat file of our seed projects. However i only
> > supplied the actual file of symbols in the "fresh-site" not in
> > the main/template-sites/basic/
> > 
> > So if people based their sites on 'forrest seed' then all would
> > be okay. However, if based on 'forrest seed-basic' then not.
> 
> All is okay now. I found a workaround and described its implementation
> in FOR-1071.

Hmm, meaning we have a dependency on this file which all sites that
updates to a future 0.9 release need to add to the custom project.

I am not too excited about this but have no time to follow up on it and
the work is too valuable to loose it. I will add a note to the update
document.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
> > 
> > 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.
> 
> Aha, i found it. When this ability for "project and core symbols"
> was added in forrest-0.8 version, i declared the project symbols
> in the xml catalog.xcat file of our seed projects. However i only
> supplied the actual file of symbols in the "fresh-site" not in
> the main/template-sites/basic/
> 
> So if people based their sites on 'forrest seed' then all would
> be okay. However, if based on 'forrest seed-basic' then not.

All is okay now. I found a workaround and described its implementation
in FOR-1071.

-David

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> 
> 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.

Aha, i found it. When this ability for "project and core symbols"
was added in forrest-0.8 version, i declared the project symbols
in the xml catalog.xcat file of our seed projects. However i only
supplied the actual file of symbols in the "fresh-site" not in
the main/template-sites/basic/

So if people based their sites on 'forrest seed' then all would
be okay. However, if based on 'forrest seed-basic' then not.

Drat, again.

-David

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Thorsten Scherler wrote:
> 
> 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.

See other reply. It does work, just poor configuration
in 'forrest seed-basic'.

> > 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

No, i tried and it does not. That gives "unknown protocol: cocoon" too.

> 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.

I reverted at r633330.

-David

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by David Crossley <cr...@apache.org>.
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

Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2008-03-04 at 00:28 +0100, Thorsten Scherler wrote:
> On Tue, 2008-03-04 at 10:21 +1100, 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). Makes me think
whether "cocoon://entity/symbols-project-v10.ent" would not work?

salu2

> 
> 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.
> 
> salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Re: dependency on project symbols file (Was: svn commit: r632740)

Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2008-03-04 at 10:21 +1100, David Crossley wrote:
> Thorsten Scherler wrote:
> > Gav.... wrote:
> > > 
> > > This may be related to this commit.
> > 
> > Not sure if exactly to this one, but to one of them.
> > 
> > > After doing : svn up; cd main; build clean; build
> > > Then doing a 'forrest seed-basic' 'forrest run' gives me :-
> > > 
> > > 17:59:29.984 EVENT  Started org.mortbay.jetty.Server@443226
> > > Failed to create InputSource (java.io.FileNotFoundException:
> > > D:\web\16degrees\sr
> > > c\documentation\resources\schema\symbols-project-v10.ent (The system cannot
> > > find
> > >  the file specified)):
> > > file:/D:/web/16degrees/src/documentation/resources/schema
> > > /symbols-project-v10.ent
> > > 
> > > .. and outputs nothing in the web browser.
> > 
> > Yeah, I see the same in a custom project. This work introduced a
> > dependency to symbols-project-v10.ent which I do not like at all!
> > 
> > We need to find a way that if that file is not in the project the
> > default is used and no error is caused. 
> 
> 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. 

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.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions