On 7/30/09 12:35 PM, David Savage wrote:
On Wed, Jul 29, 2009 at 2:36 PM, Richard S. Hall<[email protected]> wrote:
On 7/29/09 4:56 AM, David Savage wrote:
On Tue, Jul 28, 2009 at 5:35 PM, Richard S. Hall<[email protected]>
wrote:
On 7/28/09 12:21 PM, David Savage wrote:
On Tue, Jul 28, 2009 at 3:34 PM, Richard S. Hall<[email protected]>
wrote:
On 7/28/09 9:47 AM, David Savage wrote:
On Mon, Jul 27, 2009 at 4:03 PM, Richard S. Hall<[email protected]>
wrote:
On 7/27/09 8:24 AM, David Savage wrote:
On Fri, Jul 24, 2009 at 11:23 PM, Richard S.
Hall<[email protected]>
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?
I agree, it might not work in every case, but it seems like a good
place
to
start. It seems in the general case, if a type is exposed, then
someone
must
have a dependency on it or contain it somewhere in the transitive set
of
dependencies, otherwise it couldn't be exposed...
I guess the only concern I have with this approach is making sure it
doesn't get in the way of developers - i.e. the uses should be
calculated by the tooling vs expecting the developers to manage this
manually. Uses is a pretty nasty equation to calculate at runtime and
in an IDE environment where devs are cutting/refactoring code I guess
I'm just wary that it has the possibility to spin out of control and
lock up the IDE. Also should be careful at implementation time to
allow the calculation to be done in such a way as to allow caching so
it doesn't grind the IDE to a halt.
I worry about this during framework run time too! :-)
That's why we need to devise a decent algorithm that doesn't do this
and
we
can share among our subprojects that require resolving.
Yep that would certainly be very useful! One of the comments made
during the sigil contribution was regarding building a resolver API
that could be reused and implemented in different ways, either for
research purposes or to allow for different behaviours - fast, logical
error messages, extended semantics, etc. Maybe we could look at some
combination of code from Felix, OBR and Sigil to form the basis of an
API?
The key parts of the sigil resolver (I think) are:
* support for progress notifications (allows for UI analysis of
resolutions)
* pluggable repositories (i.e. sources of bundles - filesystem, obr,
etc)
* support for hierarchical repositories (allows developers to chose
where they would "prefer" to resolve resources from)
While all of this sounds good, I was more alluding the algorithm
itself...the API is the easy part if we have an algorithm that is wicked
fast. :-)
Sure, I agree it's definitely possible to build an algorithm in
isolation which is harder than the API. I just wonder whether there
would be more impetus to try solving this if there were a pluggable
API - kinda chicken and egg thing. I suspect there's a few people out
there working on this problem but they don't necessarily want to
donate the code to apache? If there were an API they could plug into
then they could develop the code prove it worked and potentially
contribute it later if they so wished? Might even spur some healthy
competition in this area...
Perhaps so. The Felix resolver API is now reasonably pluggable, just
implement Resolver, but there is no easy way to configure it...and it still
does need some improvement.
Ok that sounds like an interesting place to start, I'll have a dig
around and raise some issues or come back with some specific questions
on this in a separate thread as I think this conversation has wondered
off topic from the original point about how to express class
visibility at runtime. Uses certainly seems to have some merit for
compile time visibility...
Indeed.
For the time being, however, improving this API will be a lower priority
to me than improving the performance of the existing implementation.
However, specific issues with fairly simple resolutions are possible.
-> richard
Regards,
Dave
Also I think wicked fast depends on your scope - for a runtime the
problem is generally wiring together an order of around hundred or so
bundles? For a development environment this potentially has visibility
of a /lot/ more - i.e. in worst case all bundles ever developed. So
this could be thousands, tens of thousands (or dare I say it millions)
of bundles, solving uses in this area sounds (on first pass) pretty
scary...
Well, in Equinox they regularly talk about use cases with 1000s of bundles.
Regardless, it is not that difficult to create scenarios which are slow to
resolve when you combined hundreds of bundles with hundreds of
imports/exports with tons of "uses" constraints. I've seen them first hand.
;-)
-> richard
Obviously one step at a time and nothing stopping people improving the
algorithm now as you say, but allowing different research teams the
ability to try different algorithms in the scope of a single resolver
API sounds pretty neat to me ;)
Regards,
Dave
-> richard
Regards,
Dave
-> richard
* 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.
Regardless, it doesn't seem like a good idea to create whole new
mechanisms
to support improper use cases.
Agree in principle and I certainly want sigil to encourage best
practice OSGi development. But in real world projects the edges are
very rarely clean cut - so we need to provide migration paths at
least. I'll push this out for the time being as I have a work around
for fragments of this type - it's a bit messy but involves no new
options on require bundle at least.
Regards,
Dave
-> richard
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
