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.
