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.


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


View raw message