Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42E4D58A.6000701@odoko.co.uk>
Date: Mon, 25 Jul 2005 13:05:30 +0100
From: Upayavira <uv@odoko.co.uk>
Organization: Odoko Ltd
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] The impact of using OSGi
References: <42E4976F.30702@apache.org> <42E4C380.3050601@apache.org>
 <42E4C59A.50300@odoko.co.uk> <200507251951.37592.niclas@hedhman.org>
In-Reply-To: <200507251951.37592.niclas@hedhman.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niclas Hedhman wrote:
> On Monday 25 July 2005 18:57, Upayavira wrote:
> 
>>Well, no, it doesn't. OSGi by default doesn't do any dependency
>>resolution. Either by package, or by 'block'. In which case, if we use
>>Maven for it at build time, we're still stuck with a need for it at
>>deploy time, which seems a little odd.
> 
> There are a few issues in play here;
>   1. Depending on Services.
>   2. Depending on specific bundles.
>   3. Depending on Java interfaces, not "owned" by the current bundle.

Yup. Now, in Cocoon's 'sitemap blocks', as Stefano defined them, a block 
is identified by its namespace, and blocks depend upon each other via 
these namespaces. I'm not yet sure whether we can implement that kind of 
dependency management using point 2 above or not. I hope so!

>>Building when you depend on java code in other bundles isn't that easy.
>>For one, you may depend upon java classes which are in a jar embedded
>>within another jar. 
> 
> 3. I think it is expected that classes that a Bundle depends on for its on 
> instantiation and execution, is distributed with it (or referenced in the 
> Manifest to a global resource (probably not recommended but possible).

I don't understand quite how this could work. After all, if one bundle 
depends upon another, if that bundle includes its dependency within it, 
hasn't that killed all benefit? Or must it just include the interface 
that its dependency bundle implements? Is that what you mean?

>>Secondly, the bundle you 
>>are depending upon might only export some of its classes. Ant can't
>>specify only certain classes in its classpath (I dunno if Maven can
>>handle this). 
> 
> OSGi doesn't Import/Export classes, it only imports/exports packages. And by 
> using differnt <path> in Ant, you can make the distinction. 

See [1]. I would assume this is R4 syntax, although I can't be sure.

>>So, the only solution we were able to come up with was to 
>>explode the dependency bundle's jar, only extracting the exported
>>classes/interfaces.
> 
> Not sure what you mean here.
> 
> It seems to be a common pattern that a Bundle Jar has the "third-party 
> dependencies" in embedded Jars, while the classes "owned" by that Bundle sits 
> in the Jar root. This makes compiling easy and distribution harder, since you 
> probably want the exported classes from a Bundle to be inside your bundle.

Sorry, don't get why this makes distribution harder.

> I think there is room for a lot of improvement in the global OSGi community 
> about this. For instance, exported classes could (should?) be published as 
> Maven artifacts, and be referenced in the Manifest as artifact: URLs (I have 
> this working locally), and OSGi will resolve at runtime which bundle actually 
> exposes the exported classes.

Doesn't it do this already? How does Maven add something here?

>>This seems to me to be an OSGi specific problem, which, to my mind,
>>would be best sorted in an OSGi context.
> 
> Agree. Cocoon should probably forward "usage issues" to the incubating Oscar 
> project, and until that settles, the migration from a single Cocoon bundle to 
> use OSGi bundles in Cocoon will be somewhat 'icky'.

Yup. Move a few Cocoon devs over to Oscar and get the project going. 
Only problem is I haven't managed to get Cocoon to run with Oscar yet :-(

Regards, Upayavira

[1] http://oscar.objectweb.org/oscar-alpha.html#export-filters