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