Re: InputModule assistance

I haven't gotten a response to this on user@, so I'm trying again on d...@. Can anyone point me on the right path? Thanks, --tim On Mon, Nov 9, 2009 at 9:28 PM, Tim Williams william...@gmail.com wrote: In Forrest we've got a Locationmap InputModule.  How at runtime might we determine

XPathXMLFileModule differences

Is the new XPathXMLFileModule not a drop-in replacement for the XMLFileModule? I'm wondering if we may have been depending on some [?undocumented?] lazy-loading behavior of the old one or something. In the xconf file I have: component-instance

Re: [RANT] This Maven thing is killing us....

On 7/2/06, Sylvain Wallez [EMAIL PROTECTED] wrote: Carsten Ziegeler wrote: Now, m2 is theoretically a very good tool :) Stefano principle: you need good ideas and bad code to grow a community. I like this Stefano guy more and more every day, as I have a tendency towards both of these

Re: [RT] a simple release plan

On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: Upayavira wrote: Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond

Re: Using trunk

On 2/28/06, David Crossley [EMAIL PROTECTED] wrote: Giacomo Pati wrote: David Crossley wrote: Giacomo Pati wrote: David Crossley wrote: Would someone please help to get started with Maven. Too many days have been wasted. I have today's Cocoon trunk. Installed Maven-2.0.2 $

Re: questions on store usage

Cocoon issues. Tim Williams wrote: In forrest we've got an input module that currently has it's own simple hashmap-caching. The assumption is that the right thing to do is move away from our homegrown-cache to use the cocoon store (TRANSIENT_STORE). I presume that you are referring

another simple Store question

I need to be able to store null values in the Store. I think this is causing me problems because of MRUMemoryStore. The MRUMemoryStore docs say that it's a HashMap implementation which would support my needs well. After running out of places to look, I decided to take a look at its

questions on store usage

In forrest we've got an input module that currently has it's own simple hashmap-caching. The assumption is that the right thing to do is move away from our homegrown-cache to use the cocoon store (TRANSIENT_STORE). In doing this, I've got some potentially dumb questions. Is the store somehow

Re: Extending the image reader

On 1/30/06, Upayavira [EMAIL PROTECTED] wrote: Tim Williams wrote: I want the image reader to accept a variant name (e.g. thumb, small) and then write the newly created image variant to disk before sending the output. In other words, so that a given image IMG001.jpg might be read

[jira] Created: (COCOON-1744) NullPointerException in template block

: Tim Williams Priority: Minor Attachments: template_block.patch I have been unsuccessful actually building Cocoon so this is an untested patch. Can someone take a look and, if ok, apply to the template block? Thanks, --tim -- This message is automatically generated by JIRA. - If you think

Extending the image reader

I want the image reader to accept a variant name (e.g. thumb, small) and then write the newly created image variant to disk before sending the output. In other words, so that a given image IMG001.jpg might be read with a variant thumb and on disk would now be: IMG001.jpg IMG001.thumb.jpg

[jira] Commented: (COCOON-1542) File generator resolves to root context with empty src attribute

[ http://issues.apache.org/jira/browse/COCOON-1542?page=comments#action_12359173 ] Tim Williams commented on COCOON-1542: -- Copied over from Bugzilla... Wrapping it would help in that we would get an understandable message in return. Why even try