OSGi Bnd config is missing package in Import-Package config

[GoogleCodeExporter]

MockUtil imports classes from net.sf.cglib.proxy but this is missing from the 
BND config.

The attached patch fixes this (for mockito-core).

Original issue reported on code.google.com by jerb...@gmail.com on 4 Sep 2012 at 1:19

Attachments:

• upstream_import_package_mockito.patch

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Latest stable mockito version: 1.9.0

Original comment by jerb...@gmail.com on 4 Sep 2012 at 5:02

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Invalid

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Ok. Thanks for explaining, Brice!

Original comment by jerb...@gmail.com on 6 Sep 2012 at 1:22

[GoogleCodeExporter]

You are welcome :)

Original comment by brice.du...@gmail.com on 6 Sep 2012 at 1:50

[GoogleCodeExporter]

@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

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 19 Dec 2012 at 10:59

• Added labels: Dexmaker-Android