Le Mer 24 juillet 2013 16:17, Peter MacKinnon a écrit : > A generalization which I would disagree with in the Java space. I think > many projects > eventually reach "steady-state" where they have acquired the set of dep > bundles > they need to satisfy their runtime and test requirements. For example, > Hadoop > would not bundle multiple versions of Jetty. However, it's bundled deps > may differ > slightly (perhaps even by just API-compatible versions) say from Tomcat's > (another Hadoop dependency). And that's where you see the proliferation > of bundled > jar libraries as you walk down (up?) the dep tree. Having been involved in java packaging in the past, I can only agree with the generalization. Most java projects will affirm their bundling is minimal, but java projects are deeply interconnected and unwinding recursively the dependencies of the bundled deps (which can also do their own 'sparse' bundling) always gave frightening results in my time. Java projects only consider the tip of the iceberg. They quickly lose count of the layers of obsolete components their bundled deps drag. And because they lose count, they are not aware of the security problems that caused each of those to become obsolete upstream in the first place. I wouldn't object to bundling if the bundlers did due security diligence on the bits they bundled. But they don't. That's the *only* reason they feel bundling is cheaper. They skim on the security maintenance costs. -- Nicolas Mailhot -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
