Closed GoogleCodeExporter closed 9 years ago
Hi,
Mockito is using a repackaged CGLIB, we don't rely anymore on net.sf.cglib
(since a very long time).
Which version are you using ?
Original comment by brice.du...@gmail.com
on 4 Sep 2012 at 1:38
Latest stable mockito version: 1.9.0
Original comment by jerb...@gmail.com
on 4 Sep 2012 at 5:02
Hmm, using hg browse it looks like we have different sources than the 1.9.0
tag. I will check that everything is in order on our end (Fedora).
Original comment by jerb...@gmail.com
on 4 Sep 2012 at 5:05
Oh you might be using the specific release management stuff from fedora, I
remember that someone on the ML wanted to package Mockito in an .rpm or .deb
and expose CGLIB as a dependency. That may be the result of it. You should look
in that direction.
Original comment by brice.du...@gmail.com
on 4 Sep 2012 at 5:21
Hi,
I'll change the status to Invalid. Don't hesitate to tell us how it was fixed.
Cheers,
Brice
Original comment by brice.du...@gmail.com
on 5 Sep 2012 at 9:01
FYI: I'm a Fedora packager and discovered this issue while working on mockito.
Ok. I think I've figured it out. You are repackaging a jar (cglib) in your
mockito releases. This is something we can't do in Fedora. Jars can't embed
other jars they depend on but need to use the package manager means to resolve
dependencies.
In fact, the situation isn't all that different from your hamcrest/objenesi
dependencies in an OSGi sense. The OSGi bundle org.mockito.mockito-core should
import the proxy package from net.sf.cglib. org.mockito.mockito-all could
perhaps include net.sf.cglib.
So I think this is a bug after all. Having said that, it looks with upcoming
1.9.5 this situation might be a bit different (judging from a quick glance at
the sources).
Original comment by jerb...@gmail.com
on 5 Sep 2012 at 10:39
Actually, if CGLIB is repackaged and not objenesis or hamcrest is because there
have been funky issues in CGLIB that causes problems at runtime. Ola Bini
blogged about ~4 years ago and proposed to repackage CGLIB as others did. While
the bug should be fixed in CGLIB, we are not keen to dive this code base.
There have been some activities recently on the CGLIB project, maybe this issue
will be fixed and will allow us to get rid of a repackaged CGLIB.
Anyway, at this point the repackaged CGLIB shouldn't be considered an external
dependency, but rather a bundled component. (Also note that it's not really a
jar in a jar, but rather the package name 'net.sf.cglib.*' that changed to
become 'org.mockito.cglib.*'). If the Fedora flavoured Mockito come with
unpackaged CGLIB, then we are not responsible of this.
About 1.9.5, we didn't removed CGLIB but rather exposed the MockMaker API, to
allow third party builder to provide their own mock maker (think Dexmaker for
Android).
Cheers,
Brice
Original comment by brice.du...@gmail.com
on 5 Sep 2012 at 11:42
Ok. Thanks for explaining, Brice!
Original comment by jerb...@gmail.com
on 6 Sep 2012 at 1:22
You are welcome :)
Original comment by brice.du...@gmail.com
on 6 Sep 2012 at 1:50
@jerboaa, feel free to suggest some solution that can make Fedora work easier.
However, we would want to keep using repackaged cglib/asm to avoid runtime
issues.
Original comment by szcze...@gmail.com
on 18 Sep 2012 at 9:32
Original comment by brice.du...@gmail.com
on 19 Dec 2012 at 10:59
Original issue reported on code.google.com by
jerb...@gmail.com
on 4 Sep 2012 at 1:19Attachments: