I'd like to point out one more idea in addition to Michael's list.
4) Supporting a finer grained packaging.
What do I mean by this? For an application specific runtime environment it's
rather easy to identify stuff you don't want. It's very unlikely that you'll
need AWT/Swing on a headless webserver. Following Michael's strategy 1), you'll
build classpath with --disable-gtk-peer, possibly remove unused classes from
glibj.zip, and you're finished.
However, this doesn't work too well for distributions (like Familiar) which aim to provide a universally usable
set of packages. This "one-size-fits-all" approach sounds like it has to collid
with the aim of consuming as little precious flash space as possible, doesn't it?
Well, the easy way out - packaging different build configurations - isn't an
option really, since that would result in conflicting packages and
a general maintenance nightmare.
A more clever way is to use one build time configuration covering a wide range
of use cases and to split the result
into as many packages as reasonably possible. E.g., the current kernel packaging
code in OpenEmbedded creates one package
per kernel module. The same goes for GStreamer modules and glibc localedata just to
name a few. This also helps reduce runtime dependencies for core functionality
of a given software component (which isn't a new idea of course if you look at gnuplot in debian for example).
Obviously, I'd like GNU Classpath to support something similar. The native
libraries (libgtkpeer.so in particular) can be packaged separately already.
What's left is one big (in embedded terms rather giant) glibj.zip. Splitting
that up isn't a trivial task due to partly less than obvious (java) package
interdependencies etc.
Any pointers as to how this could be accomplished would be appreciated (packaging AWT/Swing separately is what users request most frequently btw).