cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [osgi] metadata
Date Mon, 04 Jul 2005 13:20:06 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:
>>> I still like the idea of automatically generating the OSGi manifest 
>>> :-). All the general properties (author, documentation, ...) are 
>>> available in block.xml
>> Yes, OTH, I believe that it is in general an anti pattern to have two 
>> reduntant versions of essentially the same info. Considering the 
>> popularity of Eclipse, there will be many people that have experience 
>> with OSGi manifest files, and that will find it confusing to specify 
>> esentially the same info somewhere else. Also take into account that 
>> the Eclipse developers decided to deprecate parts of pluggin.xml, 
>> which is rather well spread, in the interest of avoiding redundancy. 
>> As nothing, except for some experimental code and some webpages is 
>> dependent on the format of block.xml we have far less restrictions 
>> than they have.
> Are you proposing to skip block.xml and only have the OSGi manifest or 
> reducing block.xml and putting every redundant piece of information 
> into the OSGi manifest?

The later, let the OSGi manifest package dendencies and what happens to 
be part of the manifest. Then block.xml specifies whats need to be 
specified at the component level and sitemap level.

IMO we should make it easy for the Cocoon blocks to coexist and 
colloborate with "pure" bundles (without any Cocoon dependencies) or 
Eclipse plugins (if you deploy the needed Eclipse framework bundles).

But it becomes rather abstract to discuss how to split (or not) the 
configuration files at this point. We have to let that develop while we 
get more experience from implementing the different layers.

> I don't think that those general meta information are the real problem 
> but the dependency information. The declared dependencies should be 
> the same for the OSGi layer, component management and the sitemap 
> layer. Declaring them twice will lead to a big mess.
>>> and the information about the exported packages can also be 
>>> generated if we seperate between public (exported) and internal 
>>> classes and libraries within our directory structure.
>>> [block]
>>>   - src
>>>     - java
>>>        - public
>>>          com/mycompany/project/xyz
>>>          ...
>>>        - internal
>>>          com/mycompany/project/xyz/impl
>>>          ...
>>>   - lib
>>>      - public
>>>      - internal
>>> The information about the imported packages can be looked up in the 
>>> OSGi manifest of the required block, again at build time.
>> Yes, in some ideal case this would be nice. But given that our 
>> current set of blocks doesn't fullfill any such standards we 
>> propbably have to do a lot of exports and imports by hand.
> here we will have to do a lot of refactoring in any case as we have to 
> adapt our package name structure IIU OSGi and one of your previous 
> mails correctly. Moving around some packages will not be the problem 
> (with SVN and Eclipse).

That's true. What I meant is that we for some of the current blocks and 
for the Cocoon core might need to have back compatible solutions with 
package structure that is less easy to automatically export and import.

>> Automatically importing things that one don't need from another block 
>> is not necessarilly a good idea as it imposes more constraints than 
>> necessary and make it harder to change dependecies if one want to.
> if it's only about the Import-Package property than I'd say that we 
> should include them into block.xml as _I_ prefer XML for properties. 
> Using some XML editor that supports XML schema (e.g. OxygenXML) will 
> make editing the block descriptor very easy.

I also like XML, but not as much as I dislike unnecessary redundancy ;)

>>> In short, I think that we (usually) don't have to put import/export 
>>> packages information into it.
>>> Of course, keeping the OSGi manifest and block.xml seperate is 
>>> always an option. Making the block build process handle both 
>>> scenarios shouldn't be difficult.
>>> ---
>>> I'm a bit confused about the relation between import/export package 
>>> and Require-Bundle. Does anybody know about this?
>> Require-Bundle is part of Eclipse and possibly of OSGi R4 see 

>> and
> thanks, will read it (I think we should create a wiki page with all 
> the OSGi information we (you) have collected so far)

Sounds like a good idea ;)


View raw message