matthew.hawthorne wrote:
I see your point, but keep in mind that this was done to make the lives
of the users easier. Forcing a user to include a huge [collections] jar
for a project that only uses 1 or 2 classes from it doesn't seem
practical to me.
Well, there's always the tradeoff between
1. providing many small jars, thereby creating lots of dependencies
and making versioning hard, and
2. providing a few large jars, thereby keeping the dependency graph
small but making it harder to upgrade small parts and providing the
feeling a lot of unnecessaary things are loaded into memory
One solution is to provide a tool which packages only used classes
and their dependencies into one or a few custom jars. Unfortunately,
the dependency tracking mechanism needs some metadata to track
dependencies created by data driven class loading.
A possiblity to get around this would be a tool which notifies classes
used during compilation and JUnit test runs and creates a customized
jar from the pool of library and program classes in the deployment
stage.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
