cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [cron block] dependency question
Date Thu, 21 Oct 2004 14:50:55 GMT
Unico Hommes wrote:
> Reinhard Poetz wrote:
> 
>> Unico Hommes wrote:
 >>
>> Some thoughts I want to share:
>>
>> goal: move towards real blocks - do as much work that can be reused later
>>
>> - each block has its own build system
> 
> IIRC, Nicola already started an effort for an updated build system that 
> features an individual build file for each block separately. I wonder 
> what happened to that and whether it is useable already.
> 
>> - each block has a public and a private directory
> 
> What does that do?

uups, I mean a public and a private source directory. Other blocks mustn't 
depend on private classes

>> - each block has a deployment descriptor:
>>   * list of blocks that are necessary to make them compile/run
>>   * list of blocks that are necessary at runtime
>>     (e.g. forms needs xsp because of the examples)
>>   * list of all libraries
>>     (all libraries are in a single Cocoon library repository
>>      and this way we can make sure that we don't end at jar hell
>>      --> real block and their shielding will finally solve this)
>>   --> create gump file
>>   -<-> create eclipse/idea project files
>> - each block only depends on
>>   - cocoon core
>>   - public sources of other blocks
>>
> 
> This is the same file as blocks.xml for real blocks right?

Yep only stripped down for our current needs

> 
>> a complete build runs through following steps:
>>
>> - compile Cocoon core
>> - one build task that compiles all public directories
>>   at once (or can we make sure that there are no
>>   circular dependencies, which should be avoided of
>>   course)
>> - compile each block separatly
>> - create web application
>> - deploy each block separatly
>>   - copy samples
>>   - patch configuration files
>>
>> but of course only a single block can be deployed too
>>
>> It's probably a lot of work but sooner or later we have to do it 
>> anyway, so why should we suffer from our build system and a gigantic 
>> eclipse project any longer
>>
> 
> For splitting the eclipse project there is an additional requirement 
> that blocks and core directory don't overlap. Eclipse cannot deal with 
> overlapping projects. So that would mean that the 2.2 core move to 
> /repos/asf/cocoon/trunk/core .

IMO the eclipse project file for a block contains

- two source directories (public/private)
- Cocon core lib
- public libraries of blocks it depends on
- external libraries (currently in lib/optional)

This way we don't have to deal with Eclipse project dependencies, do we?

-- 
Reinhard

Mime
View raw message