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 Wed, 10 Aug 2005 13:46:23 GMT
Daniel Fagerstrom wrote:
> Upayavira wrote:
> 
>> Carsten Ziegeler wrote:
>>
>>> Daniel Fagerstrom schrieb:
>>>
>>>
>>>>> From the discussions last week with Reinhard, Daniel and Upayavira 
>>>>> I think using block.xml to generate everything else was the 
>>>>> consensus. See "role of block.xml" in 
>>>>> http://wiki.apache.org/cocoon/Blockathon2005Report
>>>>
>>>>
>>>>
>>>>
>>>> Hmm, was I really part of that concensus? Like Sylvain I prefer to 
>>>> use the OSGi manifest for everything that can be described by that 
>>>> and the block.xml for the rest.
>>>>
>>>> Now, IIUC, the rest of you think that such a solution would be 
>>>> unpractical because of overlap with gump, compile and deploy time 
>>>> dependency descriptors etc. You might very well be right about that, 
>>>> but I prefer to wait and see until we actually start to implement it 
>>>> before we decide.
>>>>
>>>
>>> I prefer a single source of information about a block: the block.xml -
>>> we can then generate everything else out of. This would also keep us
>>> independent from OSGi.
>>> But you're we can start in any way and then change it later on. For
>>> converting an xml to another xml we just need a stylesheet anyway.
>>
>>
>>
>> Yes. To change isn't hard. And, I think experience will guide us. Is 
>> it more important to be able to use standard OSGi bundles within 
>> Cocoon, or to have Cocoon bundles work outside of Cocoon itself, or to 
>> have a Cocoon 'block' as being something that has, from a developer's 
>> point of view, nothing specifically to do with OSGi.
> 
> 
> At some point in time, e.g. now ;) we need to decide that we go for 
> OSGi. Keeping all roads open at all time means that we just reinvent 
> whats allready is standardized in OSGi.

I think that is a different question. I'm all for committing to OSGi, 
after all, we can always roll back as we did with Fortress. Maybe what 
we should do is 'tag' the repository now, before we do anything 
invasive, to make that option simpler. However, I think we have a 
general consensus to push forward with OSGi.

> For functionality that we allready have, we must of course respect back 
> compability and write wrappers beween what we have and the new OSGi 
> based implementations. But for new functionallity I think that we should 
> reuse as much as possible of what allready is in OSGi.

Again, I think the question I was answering is different. The question 
is, what if a piece of configuration information is needed by OSGi _and_ 
Cocoon, because our use-case is broader than that of OSGi. Should we use 
the manifest.mf file and have our own systems consume that as well as 
OSGi, or alernatively use the block.xml file, and have manifest.mf 
generated from that.

And that, I think, is a question we don't need to resolve right away.

>> And these questions we should be able to answer a little further down 
>> the road.
> 
> Exactly, we should let our practical experiences when we start to work 
> at it decide.

Yup.

Regards, Upayavira

Mime
View raw message