felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Automatic generation of Import-Package statements
Date Tue, 06 Jun 2006 11:12:04 GMT
On Monday 05 June 2006 21:29, Thomas Watson wrote:
> If I follow you correctly, you are stating that you are not willing to get
>
> the wicket packages from another bundle.  If that is the case then I would
>
> suggest you not explicitly import the wicket packages.  Or is this just
> a temporary issue that you hope to allow for in the final version of your
> bundle?

ATM, it is not totally clear whether we have covered the cases and are willing 
to receive the packages from another bundle. I think it will work, and sooner 
or later we are going to have that sorted out...

> I'm picking on your particular example because of the various issues that
> need to be considered while using automated tools.  If the tools have
> unreasonable defaults then many developers will fall into the same issues.

Sure.

> I think it is vitally important that a developer carefully considers every
> package they import because of the ramifications of such a decision.
> For example, how does the tool know what version of the package you need?
> This becomes even more important if you export that package.  Maybe you
> export the package at version 2.1 but you can actually use version 2.0 if
> it is already available on the framework.  I'm not sure an automated tool
> will be able to make such developer orientated decisions.

Well, computers are dumb. But I am also dumb. Example; how many times have one 
deployed a system with a missing classpath entry which doesn't trigger until 
some sysop decides to enable a runtime feature? Classic example; Mail 
delivery of Log Events. "Oops, mail.jar was not on classpath. Need to take 
the system down."

I'd rather be given an exhaustive list of things that *may* be required, and 
remove stuff from it, than creating a list from scratch. Maybe that is just 
me. Perhaps other OSGi veterans can provide some opinion...

And I am still stunned by the statement that the framework will not deliver 
q-1.0 to my BundleC if the exporter of q-1.0 imports q, which is resolved to 
q-1.1 exported by someone else...
Can't find it in the spec to neither confirm nor contardict it either, and 
Richard's reply is also vague on the point...


Cheers
Niclas

Mime
View raw message