You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/01/01 14:53:37 UTC
Forrest TODO list
Hi,
Hope you all had a good break.
I think it would be a good idea to get some sort of Forrest Roadmap
happening, to figure out what needs to be done, what the priorities are,
and who is willing to do what.
Here is a list of things I can think of. Please add to it, and indicate
what you think is most important. Maybe later we can break this up and
add it to JIRA. I think JIRA has XML export, so maybe we could create a
'todo' tab in Forrest, linking to each item. Er.. add that to the
'medium term' list :)
Short term
----------
- Fix or work around the images-in-PDF problem [1].
- Fix the logging (logkit.xconf) to stop Cocoon generating 370k (!) of
logs per page rendered.
- Fix whatever it is that causes Jisp to fill error.log with these:
ERROR (2002-12-25) 23:15.44:410 [core.store.persistent] (/forrest/community/index.html) Thread-13/JispFilesystemStore: get(..): Exception
com.coyotegulch.jisp.DatabaseException: no indexes associated with this database
at com.coyotegulch.jisp.IndexedObjectDatabase.<clinit>(IndexedObjectDatabase.java:88)
at org.apache.cocoon.components.store.JispFilesystemStore.initialize(JispFilesystemStore.java:237)
at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:275)
at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
Medium term
-----------
- Optimise the CLI to deal with Javadocs, and other large sets of
pre-generated content. Apparently if Javadocs are placed in
src/documentation/content/javadocs, they will be traversed, but far too
slowly to be of practical use.
- Figure out a way of traversing images specified in CSS. Stefano's
suggestion [2] looks good.
- Simplify the sitemap. It is getting rather complex, and as the source
of Forrest's power we need it to be accessible to newcomers.
I'd suggest moving all the stuff specific to Forrest's site
(apachestats, community/revision stuff, libre, .dtdx, editor) out into
a Forrest site-specific sitemap.xmap. Move anything else that can be
moved into subsitemaps. Perhaps using XML entities to suck in bits of
sitemap would be a decent way to manage future sitemap complexity, at
least until Cocoon Blocks arrive. Perhaps we can add XInclude support
to the sitemap?
- Fix things so docs can be edited in src/*, and have the changes appear
immediately in the webapp. Involves creating/using an InputModule for
passing 'forrest.skin' and other properties to the sitemap, so we can
avoid the @skin@ hack, and a bit of forrest.build.xml hacking. There
are some @tokens@ in a forrest-site CSS file that also need some sort
of in-place modification. Perhaps a @token@-to-value Transformer could
be the same ${variable}-to-value Transformer mentioned in the RT [3].
- Act on 'Entities in XML docs' RT [3]. I can implement Stefano's
suggested solution quite easily, but is such limited functionality
worth the cost of introducing a proprietary ${variable} syntax? Maybe..
Best short-term alternative seems to be using the XNI XInclude
processor for pre-validation inclusion.
- Finish linkmaps, currently sitting in LINKMAP_BRANCH, I'd like to make
site.xml much more LSB-like, with file/folder element names and RDF
file metadata.
- Skinify Miles Elam's forrest.iguanacharlie.com CSS mockup. The rounded
tabs would require the CSS image traversal fix, but it's not essential.
- Schema issues. There are lots of change requests (see
etc/DTD_DEFICIENCIES.txt) and an immediate need for some sort of DTD
versioning policy.
- Docs. A lot of the info on the website is outdated. With metadata
from site.xml, it would at least be possible to indicate how old the
doc is, and perhaps indicate its relevance from a small controlled
vocabulary.
Long-term
---------
- Migrate to a decent schema language, primarily so that we can use
namespaces in XML docs, allowing things like XInclude, in-line metadata
[4], in-line SVG, Jelly snippets, or anything else users can make a
Transformer for.
- Streamline the process of adding support for new schemas. Ideally we'd
have an auto-download system, eg 'forrest-update docbook' would fetch
and install the Docbook DTDs, create catalog entries, sitemap mods etc.
- Create a forrest-users list, so we can have flaming rows on forrest-dev
over arcana without annoying users :)
- Create a Forrest Maven plugin. This is probably the biggest single way
to widen Forrest's exposure and attract new users.
--Jeff
[1] http://marc.theaimsgroup.com/?t=104065768300003&r=1&w=2
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=103975237116577&w=2
[3] http://marc.theaimsgroup.com/?t=104099660500001&r=1&w=2
[4] http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html
RE: Forrest TODO list
Posted by John Morrison <jo...@ntlworld.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Keiron Liddle wrote:
> > On Wed, 2003-01-01 at 14:53, Jeff Turner wrote:
> >
> >>Short term
> >>----------
> >>
> >>- Fix or work around the images-in-PDF problem [1].
> >
> > So what are the chances of using cvs Fop, where this problem is solved?
> >
>
> As I've previously suggested, I'm +1 to use CVS Fop and CVS Cocoon.
Sounds OK to me (+1 to both)
J.
Re: Forrest TODO list
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Keiron Liddle wrote:
> On Wed, 2003-01-01 at 14:53, Jeff Turner wrote:
>
>>Short term
>>----------
>>
>>- Fix or work around the images-in-PDF problem [1].
>
> So what are the chances of using cvs Fop, where this problem is solved?
>
As I've previously suggested, I'm +1 to use CVS Fop and CVS Cocoon.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest TODO list
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Thu, 2003-01-02 at 14:31, Avik Sengupta wrote:
> > So what are the chances of using cvs Fop, where this problem is solved?
>
> Keiron had earlier sent instructions on using the cvs FOP and patched
> cocoon (thanks!). However, this is what i got .. so i imagine some more
> patching is required somewhere :))
I was getting that problem too.
This seemed to be a temporary cocoon change, I just checked and it works
(as of 1 hour ago)
> Setup...ERROR 2003-01-02 18:59:03.482 [cocoon.m] (): The component
> instance for hint [cocoon] has an invalid class name
> (org.apache.cocoon.components.source.impl.CocoonSourceFactory).
> java.lang.ClassNotFoundException:
> org.apache.cocoon.components.source.impl.CocoonSourceFactory
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
> Exception in thread "main" java.lang.NoSuchMethodError
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:370)
> at
> org.apache.cocoon.components.resolver.ResolverImpl.<init>(ResolverImpl.java:107)
> at java.lang.Class.newInstance0(Native Method)
> at java.lang.Class.newInstance(Class.java:232)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:163)
> at
> org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
> at
> org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:268)
> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
> at org.apache.cocoon.Main.main(Main.java:419)
> at
> org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:259)
> ERROR 2003-01-02 18:59:03.487 [cocoon.m] (): Caught an exception
> trying to initialize the component handler.
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:460)
> at
> org.apache.avalon.excalibur.xml.JaxpParser.service(JaxpParser.java:115)
> org.apache.avalon.framework.configuration.ConfigurationException: The
> component instance for hint [cocoon] has an invalid class name
> (org.apache.cocoon.components.source.impl.CocoonSourceFactory).
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:248)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:383)
> at
> org.apache.avalon.excalibur.pool.ResourceLimitingPool.newPoolable(ResourceLimitingPool.java:629)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
> at
> org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:359)
> at
> org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:188)
> at
> org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
> at
> org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:234)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:262)
> at org.apache.cocoon.Main.main(Main.java:419)
> at
> org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:259)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:460)
> at
> org.apache.excalibur.xmlizer.impl.AbstractXMLizer.service(AbstractXMLizer.java:51)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:248)
> at
> org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentSelector.addComponent(ExcaliburComponentSelector.java:690)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:371)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
> at
> org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
> at org.apache.cocoon.Main.main(Main.java:419)
>
> On Thu, 2003-01-02 at 18:27, Keiron Liddle wrote:
> > On Wed, 2003-01-01 at 14:53, Jeff Turner wrote:
> > > Short term
> > > ----------
> > >
> > > - Fix or work around the images-in-PDF problem [1].
> >
> > So what are the chances of using cvs Fop, where this problem is solved?
> >
> >
> >
>
>
>
Re: Forrest TODO list
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Avik Sengupta" <av...@apache.org>
> > Why are you tinkering with the Cocoon config, resolver.jar etc? The
> > version of Cocoon in Forrest CVS is quite recent, and includes all the
> > cocoon.xconf modifications required.
> >
> > --Jeff
> Oh, i just wanted to be able to put images in pdf's, for which i believe i
> need FOP HEAD cvs, and therefore a patched version of cocoon HEAD.
>
Then it'd be much better to raise this on Cocoon Dev list so we could just
update Cocoon in Forrest and not maintain a special patched version of it.
--
Konstantin
Re: Forrest TODO list
Posted by Avik Sengupta <av...@apache.org>.
> Why are you tinkering with the Cocoon config, resolver.jar etc? The
> version of Cocoon in Forrest CVS is quite recent, and includes all the
> cocoon.xconf modifications required.
>
> --Jeff
Oh, i just wanted to be able to put images in pdf's, for which i believe i
need FOP HEAD cvs, and therefore a patched version of cocoon HEAD.
Re: Forrest TODO list
Posted by Jeff Turner <je...@apache.org>.
On Tue, Jan 07, 2003 at 06:26:57PM +0530, Avik Sengupta wrote:
> Well, more experimentation!. Changed the xconf as suggested by Jeff,
> checked up on the libs. Had to change the resolver.jar, both in forrest
> and centipede. As a result, forrest refused to validate the docs
>
> validate-xdocs:
> Warning: External catalogfiles will be ignored
>
> (Nicola.. any ideas??)
>
> On setting forrest.properties not to validate, i go slightly ahead, but
> not much. Now i am stuck at
>
> Caused by: java.lang.ClassNotFoundException:
> org.apache.cocoon.components.modules.input.RequestContextPathModule
> at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
>
> This class is in the cocoon package, but does seem to be present in the
> cocoon.jar i just built. Any ideas?
Why are you tinkering with the Cocoon config, resolver.jar etc? The
version of Cocoon in Forrest CVS is quite recent, and includes all the
cocoon.xconf modifications required.
--Jeff
Re: Forrest TODO list
Posted by Avik Sengupta <av...@apache.org>.
Well, more experimentation!. Changed the xconf as suggested by Jeff,
checked up on the libs. Had to change the resolver.jar, both in forrest
and centipede. As a result, forrest refused to validate the docs
validate-xdocs:
Warning: External catalogfiles will be ignored
(Nicola.. any ideas??)
On setting forrest.properties not to validate, i go slightly ahead, but
not much. Now i am stuck at
Caused by: java.lang.ClassNotFoundException:
org.apache.cocoon.components.modules.input.RequestContextPathModule
at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
This class is in the cocoon package, but does seem to be present in the
cocoon.jar i just built. Any ideas?
On Thu, 2003-01-02 at 20:29, Jeff Turner wrote:
> On Thu, Jan 02, 2003 at 07:01:11PM +0530, Avik Sengupta wrote:
> > > So what are the chances of using cvs Fop, where this problem is solved?
> >
> > Keiron had earlier sent instructions on using the cvs FOP and patched
> > cocoon (thanks!). However, this is what i got .. so i imagine some more
> > patching is required somewhere :))
> >
> > Setup...ERROR 2003-01-02 18:59:03.482 [cocoon.m] (): The component
> > instance for hint [cocoon] has an invalid class name
> > (org.apache.cocoon.components.source.impl.CocoonSourceFactory).
> > java.lang.ClassNotFoundException:
> > org.apache.cocoon.components.source.impl.CocoonSourceFactory
>
> I think that is (or was) a regression on Cocoon's part. I had to make the
> following change to cocoon.xconf when updating Forrest's Cocoon:
>
> - <component-instance class="org.apache.cocoon.components.source.impl.CocoonSourceFactory" name="cocoon"/>
> + <component-instance class="org.apache.cocoon.components.source.impl.SitemapSourceFactory" name="cocoon"/>
>
>
> --Jeff
>
Re: cvs Cocoon and FOP (was Re: Forrest TODO list)
Posted by David Crossley <cr...@indexgeo.com.au>.
Did you try cleaning out your ./build/ directory?
There was a major update of some jars recently.
--David
Avik Sengupta wrote:
> Latest cvs cocoon gives me the same error, and changing the xconf as
> suggested below gives me the exception below :( .. ill play around a bit
> more and see what i can come up with!
>
> Exception in thread "main" java.lang.NoSuchMethodError
> at
> org.apache.cocoon.components.resolver.ResolverImpl.<init>(ResolverImpl.java:107)
> at java.lang.Class.newInstance0(Native Method)
> at java.lang.Class.newInstance(Class.java:232)
> at
<snip/>
cvs Cocoon and FOP (was Re: Forrest TODO list)
Posted by Avik Sengupta <av...@apache.org>.
Latest cvs cocoon gives me the same error, and changing the xconf as
suggested below gives me the exception below :( .. ill play around a bit
more and see what i can come up with!
Exception in thread "main" java.lang.NoSuchMethodError
at
org.apache.cocoon.components.resolver.ResolverImpl.<init>(ResolverImpl.java:107)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:232)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:163)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:268)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:259)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:460)
at
org.apache.avalon.excalibur.xml.JaxpParser.service(JaxpParser.java:115)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:248)
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.newPoolable(ResourceLimitingPool.java:629)
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:359)
at
org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:188)
at
org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:234)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:262)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:259)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:460)
at
org.apache.excalibur.xmlizer.impl.AbstractXMLizer.service(AbstractXMLizer.java:51)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:248)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.addComponent(ExcaliburComponentSelector.java:690)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:371)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
at org.apache.cocoon.Main.main(Main.java:419)
Setup...
On Thu, 2003-01-02 at 20:29, Jeff Turner wrote:
> On Thu, Jan 02, 2003 at 07:01:11PM +0530, Avik Sengupta wrote:
> > > So what are the chances of using cvs Fop, where this problem is solved?
> >
> > Keiron had earlier sent instructions on using the cvs FOP and patched
> > cocoon (thanks!). However, this is what i got .. so i imagine some more
> > patching is required somewhere :))
> >
> > Setup...ERROR 2003-01-02 18:59:03.482 [cocoon.m] (): The component
> > instance for hint [cocoon] has an invalid class name
> > (org.apache.cocoon.components.source.impl.CocoonSourceFactory).
> > java.lang.ClassNotFoundException:
> > org.apache.cocoon.components.source.impl.CocoonSourceFactory
>
> I think that is (or was) a regression on Cocoon's part. I had to make the
> following change to cocoon.xconf when updating Forrest's Cocoon:
>
> - <component-instance class="org.apache.cocoon.components.source.impl.CocoonSourceFactory" name="cocoon"/>
> + <component-instance class="org.apache.cocoon.components.source.impl.SitemapSourceFactory" name="cocoon"/>
>
>
> --Jeff
>
Re: Forrest TODO list
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jan 02, 2003 at 07:01:11PM +0530, Avik Sengupta wrote:
> > So what are the chances of using cvs Fop, where this problem is solved?
>
> Keiron had earlier sent instructions on using the cvs FOP and patched
> cocoon (thanks!). However, this is what i got .. so i imagine some more
> patching is required somewhere :))
>
> Setup...ERROR 2003-01-02 18:59:03.482 [cocoon.m] (): The component
> instance for hint [cocoon] has an invalid class name
> (org.apache.cocoon.components.source.impl.CocoonSourceFactory).
> java.lang.ClassNotFoundException:
> org.apache.cocoon.components.source.impl.CocoonSourceFactory
I think that is (or was) a regression on Cocoon's part. I had to make the
following change to cocoon.xconf when updating Forrest's Cocoon:
- <component-instance class="org.apache.cocoon.components.source.impl.CocoonSourceFactory" name="cocoon"/>
+ <component-instance class="org.apache.cocoon.components.source.impl.SitemapSourceFactory" name="cocoon"/>
--Jeff
Re: Forrest TODO list
Posted by Avik Sengupta <av...@apache.org>.
> So what are the chances of using cvs Fop, where this problem is solved?
Keiron had earlier sent instructions on using the cvs FOP and patched
cocoon (thanks!). However, this is what i got .. so i imagine some more
patching is required somewhere :))
Setup...ERROR 2003-01-02 18:59:03.482 [cocoon.m] (): The component
instance for hint [cocoon] has an invalid class name
(org.apache.cocoon.components.source.impl.CocoonSourceFactory).
java.lang.ClassNotFoundException:
org.apache.cocoon.components.source.impl.CocoonSourceFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
Exception in thread "main" java.lang.NoSuchMethodError
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:370)
at
org.apache.cocoon.components.resolver.ResolverImpl.<init>(ResolverImpl.java:107)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:232)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:163)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:268)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
at org.apache.cocoon.Main.main(Main.java:419)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:259)
ERROR 2003-01-02 18:59:03.487 [cocoon.m] (): Caught an exception
trying to initialize the component handler.
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:460)
at
org.apache.avalon.excalibur.xml.JaxpParser.service(JaxpParser.java:115)
org.apache.avalon.framework.configuration.ConfigurationException: The
component instance for hint [cocoon] has an invalid class name
(org.apache.cocoon.components.source.impl.CocoonSourceFactory).
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:248)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:383)
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.newPoolable(ResourceLimitingPool.java:629)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:359)
at
org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:188)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:234)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:262)
at org.apache.cocoon.Main.main(Main.java:419)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:259)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ServiceManagerProxy.lookup(DefaultComponentFactory.java:460)
at
org.apache.excalibur.xmlizer.impl.AbstractXMLizer.service(AbstractXMLizer.java:51)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:248)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.addComponent(ExcaliburComponentSelector.java:690)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:371)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:264)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
at org.apache.cocoon.Main.main(Main.java:419)
On Thu, 2003-01-02 at 18:27, Keiron Liddle wrote:
> On Wed, 2003-01-01 at 14:53, Jeff Turner wrote:
> > Short term
> > ----------
> >
> > - Fix or work around the images-in-PDF problem [1].
>
> So what are the chances of using cvs Fop, where this problem is solved?
>
>
>
Re: Forrest TODO list
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2003-01-01 at 14:53, Jeff Turner wrote:
> Short term
> ----------
>
> - Fix or work around the images-in-PDF problem [1].
So what are the chances of using cvs Fop, where this problem is solved?
Re: Forrest TODO list
Posted by Avik Sengupta <av...@apache.org>.
> It's possible currently with custom transformers and lots of manual
> sitemap hacking. I can't see how we could make this user-friendly.
Detailed documentation perhaps? My view is, i am certainly willing to
spend some time doing this, but certainly dont want to sit and figure
out the whole of cocoon. In general my thinking is, at this stage in
forrest, more documentation will get more users.
> Users don't rant, they quietly leave :)
Never heard a truer word said. True of most of the service industry,
actually!
On Thu, 2003-01-02 at 12:05, Jeff Turner wrote:
> On Wed, Jan 01, 2003 at 09:26:17PM +0100, Marc Portier wrote:
> >
> >
> > Jeff Turner wrote:
> > >Hi,
> > >
> > >Hope you all had a good break.
> > >
> >
> > yep & thx, before wishing forrest and all around a breakthrough
> > in 2003 I'ld also like to thank this group for the work all of
> > you havve been setting aside here and you Jeff, personally, for
> > the way you have been active in this project the past months...
> > quite some 'acorns' you've been dropping around :-)
>
> :) Thanks. Though I suspect in the long term, one person gleefully
> chasing rabbits down holes isn't going to do much good. Hence this
> attempt at structuring the work..
>
> ...
> > - yep, in the same region (mid-term) would be some stylesheet
> > (maybe together with some inputmodules stuff and config-file for
> > the extra data) that allows publishing the status.xml as a
> > rss.xml that people can aggregate in their blog-rolls (recent
> > thought, people with experience or good pointers, throw them on
> > the list please)
>
> It's all there, just commented out until there is a sensible way to add
> the 'extra data', specifically the project name and description. If you
> don't mind hardcoding project details in changes2rss.xsl, it should work
> today.
>
> > - also the edit-side of docs could use 'something' (really vague,
> > I know, so put it on long term unless somebody can write down
> > some sensible use cases)
>
> A simple "edit this page's XML" button, where edited content gets mailed
> to a list, would be fine for me.
>
> > - more nearby (mid-term?) something that makes the various
> > book.xml's less of a hastle (and maybe settles down if libre is
> > ever going to get somewhere or not)
>
> Already in the LINKMAP_BRANCH, book.xml's are generated dynamically from
> site.xml. I'd imagine site.xml (or it's RDF-based successor) could be
> generated by Libre. Would be a shame to waste all that code..
>
> > - equally closer by I've sensed some emerging need for decoupling
> > the 1-1 between html and pdf (as printable version) typically
> > people would like to aggregate some xdocs into one pdf (or
> > straight print-nice html in fact) and/or split up a bigger
> > document into multiple next|previous pages (given the fact that
> > some were recently making the pdf for outside vs. html for
> > interal distribution remark)
>
> It's possible currently with custom transformers and lots of manual
> sitemap hacking. I can't see how we could make this user-friendly.
>
> Seems we have two long-term routes for meeting this sort of 'advanced'
> use-case:
>
> 1) Make the sitemap user-friendly, and do our best to educate people how
> to set up custom sitemaps for this sort of thing. Beyond a certain level
> of complexity, the user has to get involved.
>
> Problem here is that, as we try to add new features to meet common
> requests, we also complicate the sitemap, making it harder for users to
> customize.
>
> 2) We try to internalise and hide the sitemap. We could have an
> arbitrarily fancy GUI interface, and dynamically generate a Sitemap
> object, containing exactly the components and features the user needs.
>
>
> This problem of growing sitemap complexity has a parallel with Ant script
> complexity. We need a sitemap equivalent of Maven or Centipede. Maybe
> Cocoon blocks will be the answer.
>
> > - on the forrestbot management web-gui: might be interesting to
> > also be able to register new skins on there, and maybe web-form
> > like submit or even edit a bot-config to add in the list.
>
> We also need a RNG schema for the forrestbot.
>
> > as for the forrest-users mailing list: my feeling would be that
> > committers still need to be subscribed to both anyway (and I'm
> > lazy :-p ), so I would leave it to non-committers to actually
> > raise the need (I mean when they start complaining about wasted
> > bandwith on for them non-relevant stuff then it is probably a
> > better time/argument than the 'we want to rant and flame in a
> > more private corner' :-))
>
> Users don't rant, they quietly leave :)
>
>
> --Jeff
>
> > regards,
> > -marc=
Re: Forrest TODO list
Posted by Marc Portier <mp...@outerthought.org>.
<snip comment="thx for learning me the word 'glee' :-) "/>
[changes2rss.xsl]
> It's all there, just commented out until there is a sensible way to add
> the 'extra data', specifically the project name and description. If you
> don't mind hardcoding project details in changes2rss.xsl, it should work
> today.
>
had no idea... missed quite a bit lately in fact
as for getting the extra-data would inputmodules be a sensible
idea? I would also avoid yet another config file, anyone with any
particular favourite?
[editing (x)document sources]
>
>>- also the edit-side of docs could use 'something' (really vague,
>>I know, so put it on long term unless somebody can write down
>>some sensible use cases)
>
>
> A simple "edit this page's XML" button, where edited content gets mailed
> to a list, would be fine for me.
>
>
don't really understand...
<snip comment="really behind on linkmaps"/>
[aggregated manuals and html-paging]
>
>>- equally closer by I've sensed some emerging need for decoupling
>> the 1-1 between html and pdf (as printable version) typically
>>people would like to aggregate some xdocs into one pdf (or
>>straight print-nice html in fact) and/or split up a bigger
>>document into multiple next|previous pages (given the fact that
>>some were recently making the pdf for outside vs. html for
>>interal distribution remark)
>
>
> It's possible currently with custom transformers and lots of manual
> sitemap hacking. I can't see how we could make this user-friendly.
maybe the saying 'breaking the 1-1' was the wrong way to put
it... I wouldn't mind to write a separate src that has some <link
type="inline" src="intro.xml"> stuff to become the source for the
aggregated pdf.
If and when (ever) it would be too much hastle to maintain these
aggregation-files there could be a way to more kind of
automate/configure it with some libre-kind of notation?
As for the paging into multiple html pages... sigh, don't really
know about that... makes more sense to allow people to
inline/reuse their smaller snippets into aggregations then the
other way around.
>
> Seems we have two long-term routes for meeting this sort of 'advanced'
> use-case:
>
> 1) Make the sitemap user-friendly, and do our best to educate people how
> to set up custom sitemaps for this sort of thing. Beyond a certain level
> of complexity, the user has to get involved.
>
> Problem here is that, as we try to add new features to meet common
> requests, we also complicate the sitemap, making it harder for users to
> customize.
>
> 2) We try to internalise and hide the sitemap. We could have an
> arbitrarily fancy GUI interface, and dynamically generate a Sitemap
> object, containing exactly the components and features the user needs.
>
>
> This problem of growing sitemap complexity has a parallel with Ant script
> complexity. We need a sitemap equivalent of Maven or Centipede. Maybe
> Cocoon blocks will be the answer.
>
<snip />
>
>>as for the forrest-users mailing list: my feeling would be that
>>committers still need to be subscribed to both anyway (and I'm
>>lazy :-p ), so I would leave it to non-committers to actually
>>raise the need (I mean when they start complaining about wasted
>>bandwith on for them non-relevant stuff then it is probably a
>>better time/argument than the 'we want to rant and flame in a
>>more private corner' :-))
>
>
> Users don't rant, they quietly leave :)
>
so they don't need a separate list any more :-)
any case, you made a point, hope I did too somewhere
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Forrest TODO list
Posted by Jeff Turner <je...@apache.org>.
On Wed, Jan 01, 2003 at 09:26:17PM +0100, Marc Portier wrote:
>
>
> Jeff Turner wrote:
> >Hi,
> >
> >Hope you all had a good break.
> >
>
> yep & thx, before wishing forrest and all around a breakthrough
> in 2003 I'ld also like to thank this group for the work all of
> you havve been setting aside here and you Jeff, personally, for
> the way you have been active in this project the past months...
> quite some 'acorns' you've been dropping around :-)
:) Thanks. Though I suspect in the long term, one person gleefully
chasing rabbits down holes isn't going to do much good. Hence this
attempt at structuring the work..
...
> - yep, in the same region (mid-term) would be some stylesheet
> (maybe together with some inputmodules stuff and config-file for
> the extra data) that allows publishing the status.xml as a
> rss.xml that people can aggregate in their blog-rolls (recent
> thought, people with experience or good pointers, throw them on
> the list please)
It's all there, just commented out until there is a sensible way to add
the 'extra data', specifically the project name and description. If you
don't mind hardcoding project details in changes2rss.xsl, it should work
today.
> - also the edit-side of docs could use 'something' (really vague,
> I know, so put it on long term unless somebody can write down
> some sensible use cases)
A simple "edit this page's XML" button, where edited content gets mailed
to a list, would be fine for me.
> - more nearby (mid-term?) something that makes the various
> book.xml's less of a hastle (and maybe settles down if libre is
> ever going to get somewhere or not)
Already in the LINKMAP_BRANCH, book.xml's are generated dynamically from
site.xml. I'd imagine site.xml (or it's RDF-based successor) could be
generated by Libre. Would be a shame to waste all that code..
> - equally closer by I've sensed some emerging need for decoupling
> the 1-1 between html and pdf (as printable version) typically
> people would like to aggregate some xdocs into one pdf (or
> straight print-nice html in fact) and/or split up a bigger
> document into multiple next|previous pages (given the fact that
> some were recently making the pdf for outside vs. html for
> interal distribution remark)
It's possible currently with custom transformers and lots of manual
sitemap hacking. I can't see how we could make this user-friendly.
Seems we have two long-term routes for meeting this sort of 'advanced'
use-case:
1) Make the sitemap user-friendly, and do our best to educate people how
to set up custom sitemaps for this sort of thing. Beyond a certain level
of complexity, the user has to get involved.
Problem here is that, as we try to add new features to meet common
requests, we also complicate the sitemap, making it harder for users to
customize.
2) We try to internalise and hide the sitemap. We could have an
arbitrarily fancy GUI interface, and dynamically generate a Sitemap
object, containing exactly the components and features the user needs.
This problem of growing sitemap complexity has a parallel with Ant script
complexity. We need a sitemap equivalent of Maven or Centipede. Maybe
Cocoon blocks will be the answer.
> - on the forrestbot management web-gui: might be interesting to
> also be able to register new skins on there, and maybe web-form
> like submit or even edit a bot-config to add in the list.
We also need a RNG schema for the forrestbot.
> as for the forrest-users mailing list: my feeling would be that
> committers still need to be subscribed to both anyway (and I'm
> lazy :-p ), so I would leave it to non-committers to actually
> raise the need (I mean when they start complaining about wasted
> bandwith on for them non-relevant stuff then it is probably a
> better time/argument than the 'we want to rant and flame in a
> more private corner' :-))
Users don't rant, they quietly leave :)
--Jeff
> regards,
> -marc=
Re: Forrest TODO list
Posted by Marc Portier <mp...@outerthought.org>.
Jeff Turner wrote:
> Hi,
>
> Hope you all had a good break.
>
yep & thx, before wishing forrest and all around a breakthrough
in 2003 I'ld also like to thank this group for the work all of
you havve been setting aside here and you Jeff, personally, for
the way you have been active in this project the past months...
quite some 'acorns' you've been dropping around :-)
I guess we all envy the time you can put into it, but even given
that I still like to admit you'll spending it in a very
productive way...
> I think it would be a good idea to get some sort of Forrest Roadmap
> happening, to figure out what needs to be done, what the priorities are,
> and who is willing to do what.
>
yep, I like this work-list aproach, hope you'll be feeding it to
us again in apropriate portions in the running of the next
months, and don't mind bashing people for things they take up and
then leave behind (being quite good at that myself)
> Here is a list of things I can think of. Please add to it, and indicate
> what you think is most important. Maybe later we can break this up and
> add it to JIRA. I think JIRA has XML export, so maybe we could create a
> 'todo' tab in Forrest, linking to each item. Er.. add that to the
> 'medium term' list :)
>
- yep, in the same region (mid-term) would be some stylesheet
(maybe together with some inputmodules stuff and config-file for
the extra data) that allows publishing the status.xml as a
rss.xml that people can aggregate in their blog-rolls (recent
thought, people with experience or good pointers, throw them on
the list please)
- also the edit-side of docs could use 'something' (really vague,
I know, so put it on long term unless somebody can write down
some sensible use cases)
- more nearby (mid-term?) something that makes the various
book.xml's less of a hastle (and maybe settles down if libre is
ever going to get somewhere or not)
- equally closer by I've sensed some emerging need for decoupling
the 1-1 between html and pdf (as printable version) typically
people would like to aggregate some xdocs into one pdf (or
straight print-nice html in fact) and/or split up a bigger
document into multiple next|previous pages (given the fact that
some were recently making the pdf for outside vs. html for
interal distribution remark)
- on the forrestbot management web-gui: might be interesting to
also be able to register new skins on there, and maybe web-form
like submit or even edit a bot-config to add in the list.
as for the forrest-users mailing list: my feeling would be that
committers still need to be subscribed to both anyway (and I'm
lazy :-p ), so I would leave it to non-committers to actually
raise the need (I mean when they start complaining about wasted
bandwith on for them non-relevant stuff then it is probably a
better time/argument than the 'we want to rant and flame in a
more private corner' :-))
regards,
-marc=
>
> Short term
> ----------
>
> - Fix or work around the images-in-PDF problem [1].
>
> - Fix the logging (logkit.xconf) to stop Cocoon generating 370k (!) of
> logs per page rendered.
>
> - Fix whatever it is that causes Jisp to fill error.log with these:
>
> ERROR (2002-12-25) 23:15.44:410 [core.store.persistent] (/forrest/community/index.html) Thread-13/JispFilesystemStore: get(..): Exception
> com.coyotegulch.jisp.DatabaseException: no indexes associated with this database
> at com.coyotegulch.jisp.IndexedObjectDatabase.<clinit>(IndexedObjectDatabase.java:88)
> at org.apache.cocoon.components.store.JispFilesystemStore.initialize(JispFilesystemStore.java:237)
> at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:275)
> at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
> at org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
>
>
> Medium term
> -----------
>
> - Optimise the CLI to deal with Javadocs, and other large sets of
> pre-generated content. Apparently if Javadocs are placed in
> src/documentation/content/javadocs, they will be traversed, but far too
> slowly to be of practical use.
>
> - Figure out a way of traversing images specified in CSS. Stefano's
> suggestion [2] looks good.
>
> - Simplify the sitemap. It is getting rather complex, and as the source
> of Forrest's power we need it to be accessible to newcomers.
> I'd suggest moving all the stuff specific to Forrest's site
> (apachestats, community/revision stuff, libre, .dtdx, editor) out into
> a Forrest site-specific sitemap.xmap. Move anything else that can be
> moved into subsitemaps. Perhaps using XML entities to suck in bits of
> sitemap would be a decent way to manage future sitemap complexity, at
> least until Cocoon Blocks arrive. Perhaps we can add XInclude support
> to the sitemap?
>
> - Fix things so docs can be edited in src/*, and have the changes appear
> immediately in the webapp. Involves creating/using an InputModule for
> passing 'forrest.skin' and other properties to the sitemap, so we can
> avoid the @skin@ hack, and a bit of forrest.build.xml hacking. There
> are some @tokens@ in a forrest-site CSS file that also need some sort
> of in-place modification. Perhaps a @token@-to-value Transformer could
> be the same ${variable}-to-value Transformer mentioned in the RT [3].
>
> - Act on 'Entities in XML docs' RT [3]. I can implement Stefano's
> suggested solution quite easily, but is such limited functionality
> worth the cost of introducing a proprietary ${variable} syntax? Maybe..
> Best short-term alternative seems to be using the XNI XInclude
> processor for pre-validation inclusion.
>
> - Finish linkmaps, currently sitting in LINKMAP_BRANCH, I'd like to make
> site.xml much more LSB-like, with file/folder element names and RDF
> file metadata.
>
> - Skinify Miles Elam's forrest.iguanacharlie.com CSS mockup. The rounded
> tabs would require the CSS image traversal fix, but it's not essential.
>
> - Schema issues. There are lots of change requests (see
> etc/DTD_DEFICIENCIES.txt) and an immediate need for some sort of DTD
> versioning policy.
>
> - Docs. A lot of the info on the website is outdated. With metadata
> from site.xml, it would at least be possible to indicate how old the
> doc is, and perhaps indicate its relevance from a small controlled
> vocabulary.
>
>
> Long-term
> ---------
>
> - Migrate to a decent schema language, primarily so that we can use
> namespaces in XML docs, allowing things like XInclude, in-line metadata
> [4], in-line SVG, Jelly snippets, or anything else users can make a
> Transformer for.
>
> - Streamline the process of adding support for new schemas. Ideally we'd
> have an auto-download system, eg 'forrest-update docbook' would fetch
> and install the Docbook DTDs, create catalog entries, sitemap mods etc.
>
> - Create a forrest-users list, so we can have flaming rows on forrest-dev
> over arcana without annoying users :)
>
> - Create a Forrest Maven plugin. This is probably the biggest single way
> to widen Forrest's exposure and attract new users.
>
>
>
>
> --Jeff
>
>
> [1] http://marc.theaimsgroup.com/?t=104065768300003&r=1&w=2
> [2] http://marc.theaimsgroup.com/?l=forrest-dev&m=103975237116577&w=2
> [3] http://marc.theaimsgroup.com/?t=104099660500001&r=1&w=2
> [4] http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org