cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 10:26:47 GMT
Carsten Ziegeler wrote:
> Hmm, I'm a little bit confused if I compare the two response quoted below.
> 
> I personally would prefer to go the block.xml way and create OSGi
> manifests and whatever out of it. With that approach we are still
> independent from OSGi.

Yup. I noticed that discrepancy. A few of us did discuss this - more in 
relation to Gump than manifests.

We need to clarify the nature of the dependencies that we need to define.

We have package dependencies (handled by OSGi), and bundle dependencies 
(handled by our own block management system). For example, myskin 
extends myapp block.

Which of these do we want to use to do dependency resolution?

If package dependencies are only used by OSGi, I could see some 
rationale for having them in the manifest. However, as soon as they are 
required in more than one place, I say it all goes into block.xml.

(note, we can define a package dependency now, with R4 as 
org.apache.cocoon.generation.Generator which means we can still have 
o.a.c.generation.HTMLGenerator in a separate block, with it exporting 
that class specifically (this functionality is already included in 
Oscar), so we shouldn't need to rename our packages.)

Upayavira

>>>BTW, what is the status about the dependency definition (block.xml).
>>>What are we planning to use?
> 
> 
> Sylvain Wallez wrote:
> 
>>A lot of what's was planned to be in block.xml is already defined by the 
>>OSGi bundle manifest file. So it will be stripped-down to keep only what 
>>is specific to Cocoon blocks.
>>
> 
> Upayavira wrote:
> 
>>Just replying to this bit - Daniel showed me the block.xml before he
>>left ApacheCon. It looks pretty simple. Also, given all the other
>>'dependency' files we will/might need (gump.xml, manifest, maven project
>>files, etc) in a discussion it was suggested that we're better of
>>sticking with our own blocks.xml file - we can always generate anything
>>else we want from that.
>>
>>So, AFAICS, blokc.xml stays as Stefano proposed it.
>>


Mime
View raw message