External Blocks (was Re: Flow Database stuff ( The new FOM? ))

[Geoff Howard <co...@leverageweb.com>]

Daniel Fagerstrom wrote:
> Hugo Burm wrote:
> <snip/>
> 
>> - Hibernate is LGPL.
>> This is a pain in the ass. I cannot provide a ready-to-use Hibernate 
>> cocoon
>> block because of LGPL versus Apache license issues.
> 
> You can, it can be hosted under cocoondev.org like Fins and CVSSource, 
> that booth are based on LGPL libraries. A Hibernate block under 
> cocoondev where discussed in the thread 
> http://marc.theaimsgroup.com/?t=105074471400001&r=1&w=2, but I don't 
> know if anything happened.
> 
>                            -- o --
> 
> A somewhat OT discussion about "external" blocks:
> 
> It is possible to host Cocoon blocks (I talk about the current compile 
> time installable blocks, not the forthcomming "real" blocks) outside the 
>  the Cocoon CVS. I submitted some patches to the Fins community for 
> packaging Fins as a block.
> 
> An externally hosted block consists of the block itself together with 
> some xml fragments for configuration. The installation instructions are 
> as follows:
> * download the latest cocoon-2.1
> * copy (or put a link to) your block to cocoon-2.1/src/blocks
> * patch cocoon-2.1/gump.xml and cocoon-2.1/lib/jars.xml with the 
> configuration snippets
> * ./build.sh
> not that complicated. It would be even simpler to install an external 
> block if the gump.xml and jars.xml patching was made with the xmap 
> mechanism, in that case it would be enough to copy the block to the 
> blocks directory and recompile. The main drawback with this would be 
> that the gump descriptor would have to be generated before it could be 
> used.

Couldn't you compile the code elsewhere, drop the jar in WEB-INF, and
edit the .xconf, and .xmap files you need using the xpatch task?  You
would not be able to add new things to .roles, but can't we already get
around that? (with component-instance in cocoon.xconf)  If that works,
I could help work up a target to do this stuff - it'd be pretty trivial.

Geoff

Re: External Blocks (was Re: Flow Database stuff ( The new FOM? ))

[Daniel Fagerstrom <da...@nada.kth.se>]

Geoff Howard wrote:
> Daniel Fagerstrom wrote:
> 
>> Hugo Burm wrote:
>> <snip/>
>>
>>> - Hibernate is LGPL.
>>> This is a pain in the ass. I cannot provide a ready-to-use Hibernate 
>>> cocoon
>>> block because of LGPL versus Apache license issues.
>>
>>
>> You can, it can be hosted under cocoondev.org like Fins and CVSSource, 
>> that booth are based on LGPL libraries. A Hibernate block under 
>> cocoondev where discussed in the thread 
>> http://marc.theaimsgroup.com/?t=105074471400001&r=1&w=2, but I don't 
>> know if anything happened.
>>
>>                            -- o --
>>
>> A somewhat OT discussion about "external" blocks:
>>
>> It is possible to host Cocoon blocks (I talk about the current compile 
>> time installable blocks, not the forthcomming "real" blocks) outside 
>> the  the Cocoon CVS. I submitted some patches to the Fins community 
>> for packaging Fins as a block.
>>
>> An externally hosted block consists of the block itself together with 
>> some xml fragments for configuration. The installation instructions 
>> are as follows:
>> * download the latest cocoon-2.1
>> * copy (or put a link to) your block to cocoon-2.1/src/blocks
>> * patch cocoon-2.1/gump.xml and cocoon-2.1/lib/jars.xml with the 
>> configuration snippets
>> * ./build.sh
>> not that complicated. It would be even simpler to install an external 
>> block if the gump.xml and jars.xml patching was made with the xmap 
>> mechanism, in that case it would be enough to copy the block to the 
>> blocks directory and recompile. The main drawback with this would be 
>> that the gump descriptor would have to be generated before it could be 
>> used.
> 
> 
> Couldn't you compile the code elsewhere, drop the jar in WEB-INF, and
> edit the .xconf, and .xmap files you need using the xpatch task?  You
> would not be able to add new things to .roles, but can't we already get
> around that? (with component-instance in cocoon.xconf) 

Yes I did like that before when I developed custom Cocoon components for 
my webapps. When I did that, I had to write an own build file and make 
sure that the class path contains everything that I need. It is simpler 
to just reuse Cocoons build system. And I also happen to like the block 
concept so I prefer to use that :)

> If that works,
> I could help work up a target to do this stuff - it'd be pretty trivial.

I guess I was a litle bit unclear, unfortunatly I have no cool blocks to
provide at the moment ;) I merely wanted to tell Hugo that there are ways
to publish an LGPL dependent Cocoon block, if he wanted to, (I got the 
impression that he allready had written an Hibernate block).

On the more general side I think it could be worth while to discuss how 
to construct and use external blocks. I think that Forrest and Lenya as 
well as the cocoondev projects would be easier to install and use if 
they where packaged as blocks. And as indicated in my earlier mail, the 
mechanisms are allready provided by Cocoon, even if they could be made 
somewhat easier to use.

/Daniel