On 05/07/2011 7:29 PM, James Moore wrote:
On Tue, Jul 5, 2011 at 2:59 PM, cowwoc<[email protected]> wrote:
I vote for making the common case easy and advanced case possible. Large
projects absolutely need the flexibility to choose which dependency versions
gets used. Simple projects prefer an all-in-use JAR file. I believe #4 will
make everyone happy.
I think I would make a case for a different "common case." To me, the
common case is that Guice depends on Guava. That's an incredibly
common relationship. I certainly don't want every library I use to
start shipping all of its dependencies compiled into that library,
obfuscated in some way. i just want to know the list of things that
LibraryX depends on.
Providing other options (a single jar built with special sauce so you
don't need other jars) is fine, but it's special and extra, not a
default.
Guice in particular I think doesn't need this. Are there users who a)
understand and want the complexities and utility of Guice, and b) are
clueless about libraries with dependencies? I'd be surprised if there
were anyone in that set.
I agree 100%!
To answer Sam's question about why controlling dependencies is
important, it's two-fold:
1) I don't trust JarJar. It's a great tool, but like Proguard, it'll
never work perfectly. There will always be problems where embedded
dependencies interfere with libraries outside of Guice. The only way to
avoid this is to JarJar all dependencies recursively and even then you
have to worry about non-class resource files (stuff in or around
manifest files), classes loaded by Reflection, etc.
2) We should be able to upgrade dependencies for security/performance
reasons. We don't have the luxury of waiting for the next Guice release
(averaging once every 2 years) to fix bugs in dependencies.
But most importantly of all, it's not clear to me what problem
you're trying to solve here. As James mentioned, it is highly unlikely
that users will simultaneously understand the complexities of Guice and
be clueless about libraries with external dependencies, especially when
Guice's deployment model is the exception to the rule. Most libraries do
not embed their dependencies. In the many years of reading mailing list
posts I can only recall about three incidents that were linked to mixing
incompatible dependencies. There's no need to baby us. Honest :)
Gili
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
