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.
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.
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.
/Daniel
- Re: [RT] The impact of using OSGi Daniel Fagerstrom
-
