The problem with this is that's it's hard for me to know what's useful and
what's not. It's only the library creator that could really tell that.
I guess the problem is that it depends on the part of the API you're using
from the dep. Many of the transitive deps being pulled are used by a few
classes of the dep and you may not be using those classes yourself. Ideally
that would mean splitting the API into several jar:
framework.jar
framework-hibernate.jar
framework-rcs.jar
etc.
But that's a major change and it would be hard to required projects to do
that across the board.
No, we can't require them, but hopefully users will complain loudly
enough to the project themselves. If they don't, there is nothing we can
do to guess what they depend on and what they don't. If you depend on
this library and don't want to pass on certain deps you know are bad,
that is what <exclusions/> are for. It's still not ideal.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
