felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Savage <dave.sav...@paremus.com>
Subject Re: Visibility semantics
Date Mon, 27 Jul 2009 12:24:14 GMT
On Fri, Jul 24, 2009 at 11:23 PM, Richard S. Hall<heavy@ungoverned.org> wrote:
> On 7/24/09 12:35 PM, David Savage wrote:
>> To lay my cards on the table, I kinda like resolve=compile as it dove
>> tails kinda neatly with resolution=optional, but equally it seems
>> kinda bizarre to be adding another dimension to this whole problem
>> when people are worried about the complexity of OSGi. If there is a
>> way to do this without exposing developers to it that would be /great/
>> but as with OSGi I don't think we should worry about doing the right
>> thing at the base layer IDE tools and other schemes can always
>> simpilify this whole space down again to joe blogs. I guess it's a
>> question of what is "right".
>> So I guess the end result of this email is, what are your thoughts?
>> * Is resolve=compile a good idea?
>> * Should it be resolution=compile?
>> * Any other options?
> Isn't this some form of "uses" constraint? Middle exposes Top because it
> inherits from it, so if you follow transitive "uses" constraints you could
> possibly assume that compile-time access is needed.

Hmmm you're right it certainly resembles uses - should have spotted
that myself. However I have a feeling it may get a bit hairy in
certain edge cases, i.e. Top may not be in an exported package which
could work at runtime I believe, as Middle would provide the class
path to Top?

>> * What to do about fragments?
> I don't think the fragment issue should be handled, since that is a bogus
> use case for fragments from my point of view. Fragments are intended to be
> optional extensions to the host, but in this case the host is fibbing about
> its contents because it expects to have a fragment attached to it. In
> reality, the fragment should have the exports, not the host.

Tend to agree it is a bogus scenario - if only it wasn't happening in
one of the most used OSGi libraries available :( I guess Eclipse
probably have a good reason for doing this - not sure what but I'll
give them the benefit of the doubt.

I think I've figured out a way to work around it for the time being -
which takes the pressure off from a sigil release point of view. I'll
add the fragment to the ordinary classpath vs the OSGi filtered one,
so I can at least compile against it without dragging in an external
dependency at runtime. The danger with this approach is that unwary
developers may link against a non exported package by mistake. Just
wonder if there is a way to make this work without complicating the
development model (or the sigil code) too much...

> -> richard
>> * Is anyone still there (i.e. has this email lost you all?)?
>> Regards,
>> Dave


Paremus Limited. Registered in England. Registration No. 4181472

Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA

Postal Address: 107-111 Fleet Street, London, EC4A 2AB

The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.

If you received this in error, please contact the sender and delete
the material from any computer.


View raw message