David Blevins on 30/05/08 19:53, wrote:
Personally, I favor copying the code over and jarjar'ing the asm
dependency.
Two quick questions:
"jarjar'ing" the dependency? What does that mean? I hope I'm not the
only one who isn't hip to the lingo! I guess if I knew the context
better I could work it out.
Secondly, I was wondering about the advantages of having fewer
dependencies, especially in this maven era. If something's really
great, it's fine to depend on it, surely?
The term comes from a tool that essentially read in the byte code and
repackaged it. For example changing the java package from
org.objectweb.asm to org.apache.fooproject.asm. There are other tools
that can do it now, like the maven-shade-plugin, but it was the first
that I'm aware of.
The ASM guys themselves recommend repackaging their code due to the
number of people using different versions of ASM and that some of those
versions of incompatible. Hibernate is a good example of this as they
use a really old version of ASM. As this particular library is only 40K
or so you can solve a lot of potential headaches for users by getting it
out of their way.
Thanks for the info. IIRC I experienced the problems that stemmed from that when
I upgraded an app from Spring 2 to Spring 2.1 (or close to those version
numbers) due to Hibernate 3.1 - I think I ended up downgrading Hibernate to make
it work for a period.
I strikes me that somehow it should have worked better if the developers putting
out those new versions had just talked to each other, but they didn't and a lot
of people wasted whole days on the problem. So I guess you're right.
What isn't ideal is that the user experiences and knowledge becomes fragmented.
Perhaps that's the lesser of two evils.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
