cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [osgi] metadata
Date Mon, 04 Jul 2005 13:03:15 GMT
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?

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).

> 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.

>> 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 
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/runtime/runtime.html

> and https://bugs.eclipse.org/bugs/show_bug.cgi?id=82855.

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

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message