felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Date Sat, 10 Jun 2006 12:59:16 GMT
> > 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
> karlpauls@gmail.com

Just to clarify, it takes 4 seconds when started inside eclipse :-).
Additionally, I've added some simple caching now and the result is ~5
seconds for the first time (i.e., nothing cached) and ~1 second if
nothing changed (i.e., only the cached values are used). I think that
is acceptable (given that all figures are from inside eclipse).



Karl Pauls

View raw message