Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42C92CBE.3020505@nada.kth.se>
Date: Mon, 04 Jul 2005 14:34:06 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [osgi] metadata
References: <42C8CB68.1070103@apache.org>
 <46a835fd8c30969715dfa733eb7129eb@apache.org> <42C8D560.3010301@apache.org>
 <42C8F83A.2040805@nada.kth.se> <42C9006C.5080409@apache.org>
In-Reply-To: <42C9006C.5080409@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>
>> Reinhard Poetz wrote:
>> <snip/>
>>
>>> Just want to mention that I don't think that our users need to know 
>>> about OSGi at all if they don't want. They have to describe their 
>>> block in the descriptor (block.xml) and the rest will be done 
>>> automatically.
>>
>>
>>
>> Maybe or maybe not ;) The OSGi manifest is mainly about exporting and 
>> importing Java packages, which are concerns that we haven't discussed 
>> in any detail for the block descriptor. We could put this info in the 
>> block.xml and generate the manifest file automatically from it.
>>
>> In Eclipse they didn't go that way. There was some info in their 
>> pluggin descriptor that overlapped with the OSGi manifest. They 
>> depreciated this infor from the pluggin descriptor and recommend 
>> people to use the OSGi manifest instead. I would prefer that we do 
>> the same and consider the OSGi manifest and the block.xml as taking 
>> care of different concerns.
>
>
> 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.

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

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.

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

/Daniel