In general, it is cool to be able to auto-generate the available packages. However, I don't see it being a good idea in practice.
I know. The question was more in the direction of having the possibility (not the default and no advertisement :-).
The package list should generally be a rather static set, so I don't see people wanting to re-generate this each time they start their framework for a given deployment.
Are you worried about the performance impact? Its about 4 seconds on my PowerBook 1G (~3.5 years old) including a rather complicated filter plus it would be very easy to add some caching...
A better way to use this capability would be to use it to generate your static system packages property for your config.properties file when you deploy the framework.
Well, I can see that too. I could start a small project under tools that would print all the available packages restricted by a filter argument.
Just my $0.02... -> richard
However, I still think the predefined list solution is somewhat to restrictive. Consider, for example, I want to have the javax.comm packages. Due to some restrictions (legal and availability) they must be on the system loader. My Bundle needs them hence, has a hard dependency on the javax.comm package. What do I do in regard to shipping to arbitrary platforms? If I include the javax.comm package in the package property then my bundle gets started regardless of whether the packages are actually there and if I don't it never will be started... There are some other similar scenarios I can see and, yes, one could work around all of them without including an auto-detect feature in the framework, however, all workarounds I can think of are somewhat ugly (due to involving user actions). regards, Karl -- Karl Pauls [EMAIL PROTECTED]
