OSGi-ify Mockito

[GoogleCodeExporter]

What steps will reproduce the problem?
1. looking at the jar manifest

What is the expected output? What do you see instead?
I expect to see OSGi manifest entries.

Please provide any additional information below.

Please OSGi-ify the Mockito jar.  This would eliminate the need for
3rd-party Mockito bundles.

An example of the mockito-core jar with OSGi manifest entries can be seen here:
http://www.springsource.com/repository/app/bundle/version/detail?name=com.spring
source.org.mockito&version=1.6.0

I went ahead and filed similar enhancement requests with Mockito's
dependencies.  Please consider voting/commenting on these:
org.objenesis:objenesis
  http://code.google.com/p/objenesis/issues/detail?id=7
org.hamcrest:hamcrest-core
  http://code.google.com/p/hamcrest/issues/detail?id=53#c10
junit:junit

http://sourceforge.net/tracker/?func=detail&aid=2720888&group_id=15278&atid=3652
78

Thanks

Original issue reported on code.google.com by lukewpat...@gmail.com on 29 Mar 2009 at 3:46

[GoogleCodeExporter]

An interesting discussion here is if it is sensible to OSGi-ify test 
dependencies. 

Since the test dependencies will not run in an OSGi container usually, one could
argue that this isn't important to most users. 

My biased opinion is however, is that in-container OSGi tests are going to be
important, so you will need this sooner rather than later.

Thanks Luke, for making the effort of logging these issues.

Original comment by iwein.f...@gmail.com on 30 Mar 2009 at 8:39

[GoogleCodeExporter]

Would that be enough to just put some metadata in the jar? Or would it require
changes to the code as well? 

I have little experience with OSGi. I can update the manifest according to your
example but it would be great if someone tested it :)

Original comment by szcze...@gmail.com on 30 Mar 2009 at 11:20

[GoogleCodeExporter]

Running tests within a OSGi env can help to catch odd class resolution issues 
earlier
in the game. 

On a more technical note:
I would highly recommend using BND (http://www.aqute.biz/Code/Bnd) to produce 
the
OSGi manifest.  This is the most common tool I have run into for making OSGi
compatible manifests.  It will also help in reducing maintenance of the file in 
the
long run as it inspects the classes to write the manifest for you.  I would try
running this over the code and see how close the output comes to the manifest in
spring source and tweak from there.  Managing a good OSGi manifest is something
usually best left to tools.

If a rough cut of the manifest is done I would be willing to look it over.  I 
would
like to think that I have a good enough understanding of OSGi to give some 
feedback.

Original comment by nairb...@gmail.com on 8 Apr 2009 at 3:25

[GoogleCodeExporter]

Alternatively use Bundlor
http://blog.springsource.com/2009/03/26/using-bundlor-in-eclipse/.

Bundlor is easier to use in my opinion. You can get it as a maven plugin as 
well so
you could integrate it in your build. I don't think though that managing the
dependencies for Mockito is particularly daunting to do by hand :)

Original comment by iwein.f...@gmail.com on 8 Apr 2009 at 5:33

[GoogleCodeExporter]

We are offering support as part of OPS4J Pax Exam 
(http://wiki.ops4j.org/x/BYCk) which is an integration 
framework. The test are run within the OSGi container so we do need an 
OSGI-fyed Mockito. Right now we are 
OSGi-fying mockito bundle on the fly just before installing it in the OSGi 
framework. So, an OSGi compliant 
Mockito will help.

Original comment by adreghi...@gmail.com on 19 Apr 2009 at 6:24

[GoogleCodeExporter]

Sure, we'll do it. We'll try the BND ant plugin.

Original comment by szcze...@gmail.com on 20 Apr 2009 at 7:38

[GoogleCodeExporter]

I'd like to release Mockito sometimes soon. Is there anyone who can contribute
patching our build.xml and make it generate jar with correct manifest?

Original comment by szcze...@gmail.com on 1 May 2009 at 5:16

[GoogleCodeExporter]

What timescale for the release are you looking at?  I can look into taking a 
stab at
this in about 8 hours and will likely have success within 24 hours. I have not
developed in the mockito code base before, so that is likely to be the biggest 
hurdle
for me.

Original comment by nairb...@gmail.com on 1 May 2009 at 6:04

[GoogleCodeExporter]

Cool!

I'm looking at a release in a couple of days so don't worry and go ahead. Let 
me know
if there's any problem - szczepiq at gmail.com

Original comment by szcze...@gmail.com on 1 May 2009 at 6:55

[GoogleCodeExporter]

Ok, I think I got it working :). First, here are the important parts of the 
resulting
manifest (I chose 1.7.0 for the org.mockito version, but this is really read 
from the
version.properties file - more on this later).

Export-Package: org.mockito;version="1.7.0",
 org.mockito.configuration;version="1.7.0",
 org.mockito.configuration.experimental;version="1.7.0",
 org.mockito.exceptions;version="1.7.0",
 org.mockito.exceptions.base;version="1.7.0",
 org.mockito.exceptions.misusing;version="1.7.0",
 org.mockito.exceptions.verification;version="1.7.0",
 org.mockito.exceptions.verification.junit;version="1.7.0",
 org.mockito.invocation;version="1.7.0",
 org.mockito.runners;version="1.7.0",
 org.mockito.stubbing;version="1.7.0"
Import-Package: junit.framework;version="[3.8,4)";resolution:=optional,
 org.apache.tools.ant;version="[1.7,2)";resolution:=optional,
 org.apache.tools.ant.types;version="[1.7,2)";resolution:=optional,
 org.hamcrest;version="[1.1,2)";resolution:=optional,
 org.junit.internal.runners;version="[4.5,5)";resolution:=optional,
 org.junit.runner;version="[4.5,5)";resolution:=optional,
 org.junit.runner.notification;version="[4.5,5)";resolution:=optional,
 org.junit.runners;version="[4.5,5)";resolution:=optional,
 org.junit.runners.model;version="[4.5,5)";resolution:=optional,
 org.mockito;version="[1.7,2)",
 org.mockito.configuration;version="[1.7,2)",
 org.mockito.configuration.experimental;version="[1.7,2)",
 org.mockito.exceptions;version="[1.7,2)",
 org.mockito.exceptions.base;version="[1.7,2)",
 org.mockito.exceptions.misusing;version="[1.7,2)",
 org.mockito.exceptions.verification;version="[1.7,2)",
 org.mockito.exceptions.verification.junit;version="[1.7,2)",
 org.mockito.invocation;version="[1.7,2)",
 org.mockito.runners;version="[1.7,2)",
 org.mockito.stubbing;version="[1.7,2)",
 org.objenesis;version="[1.0,2)";resolution:=optional

For the non-osgi, crowd I chose all the non internal and non-jarjar'ed packages 
to be
exported from the bundle. Next, following what is done in the spring source obr
(http://www.springsource.com/repository/app/bundle/version/detail?name=com.sprin
gsource.org.mockito&version=1.6.0)
I imported all the dependencies optionally.  If the core of mockito requires 
one of
these packages this should be changed.  Also I followed the version range
specification from the spring source obr too.  They may be a little too wide, 
but I
would rather err on the side of too wide then too skinny - but that is my 
opinion.

I am attaching a zip of all the changes, and jars that are needed. These jars 
provide
the proper version information for the packages that they export.  I tried to 
pick
versions that were close to or the same as what you had already.  Not everyone
releases OSGi from the start, so the jars have to get wrapped with the OSGi
information.  This causes them to lag behind sometimes, but with the wide 
version
ranges that are in the imports you should be ok.  The only time you are in 
trouble is
if you are using a feature only in the newer version.

I am not an ANT user, so I will leave it up to you to get the output parameter 
of the
<bnd/> directive correct. The bnd run will take the jar given on the classpath 
and
copy it to the output (more or less).  Getting things in the right place is up 
to you
and your ANT foo.

Lastly the version you specify in your version.properties file needs to follow 
the
OSGi version style: x.y.z.qualifier.  Technically you must have 3 elements and 
the
qualifier is optional. The qualifier is the only place you can have text.  For 
the
above snippets I set the version.properties file to "1.7.0".

Give it a spin, cut a snapshot, post it somewhere and I will give it a final 
look over.

Brian.

Original comment by nairb...@gmail.com on 3 May 2009 at 12:22

Attachments:

• mockito.zip

[GoogleCodeExporter]

Thanks!

Quick questions about bnd file:

1. !org.mockito.asm.util.*,  - should I have also similar entry for 
org.mockito.cglib?
2. I don't understand org.apache.tools.ant.*;resolution:=optional,  - why do I 
need
ant tools?

Original comment by szcze...@gmail.com on 3 May 2009 at 6:36

[GoogleCodeExporter]

1: For reference, the Export-Package statement:

Export-Package= !org.mockito.asm.*, \

                !org.mockito.cglib.*, \

                !org.mockito.internal.*, \

                org.mockito.*;version=${version}

So for all the packages that *exist*, don't export the org.mockito.asm.*,
org.mockito.cglib.*, and org.mockito.internal.* packages but do export all the 
other
org.mockito packages.  Now there must be a class within the org.mockito.asm 
package
that has a dependency on a class in the org.mockito.asm.util package (which 
does not
exist).  Since this package does not exist for the export package statement, bnd
believes it can import it from somewhere else, but it can't. So we tell it to 
not
bother importing it by placing the !org.mockito.asm.util.* entry in the import
package directive.  Since all the cglib dependencies exist for the export 
package
statement, we don't need to do any tweaking in the import package statement.

2. I have no clue.  I looked an looked, yet I could not find out why it was in 
there.
Some how bnd thinks that there is a class that depends on that package 
somewhere in
your code (or in asm/cglib).  Rather then not import it, which if it is needed 
would
cause the bundle to not work at all, I opted for making it optional.  That way 
if it
is needed, the package can be provided in the OSGi runtime and everything will 
work.
 (If you don't import it, there is no way to fix it other then editing the manifest.mf).

Hope this helps.

** Looking at the bnd file, the org.hamcrest and org.objenesis import lines 
should
have .* in them for good measure.  My mistake.  It should not change the 
output, but
it should be more future proof.

Original comment by nairb...@gmail.com on 3 May 2009 at 9:47

[GoogleCodeExporter]

Picking up the subject to finish it off.

1. I got rid of: !org.mockito.asm.util.*, \ This was dependency to cglib and
previously Mockito didn't include it but now Mockito includes also asm.util 
(inside
org.mockito.asm.util)

2. I got rid of: lib/build/com.springsource.org.apache.tools.ant-1.7.1.jar \, 
This is
 dependency to cglib but mockito doesn't use those features and mockito bundle
doesn't export cglib anyway. Make sense?

3. Why those entries are optional: org.hamcrest;resolution:=optional, \
org.objenesis;resolution:=optional, \ ?

4. Can I make bnd ant task just generate manifest and not the entire jar?

Original comment by szcze...@gmail.com on 18 May 2009 at 9:30

[GoogleCodeExporter]

5. Must the output jar be called org.mockito-core.1.8.0.jar ? I'd prefer
mockito-core.1.8.0.jar.

Original comment by szcze...@gmail.com on 18 May 2009 at 11:40

[GoogleCodeExporter]

Trunk version of mockito now produces osgified bundle. Can someone look at it 
if it's
ok? Check out:

svn checkout http://mockito.googlecode.com/svn/trunk/ mockito-read-only

Then just run: 'ant'

Original comment by szcze...@gmail.com on 18 May 2009 at 12:10

[GoogleCodeExporter]

As no one validated the bundle I'm releasing an OSGified candidate :( C'mon 
guys help
me here and try it. 

Fixed in trunk.

Original comment by szcze...@gmail.com on 9 Jun 2009 at 3:12

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 9 Jun 2009 at 3:15

• Added labels: Milestone-Release1.8

[GoogleCodeExporter]

Sorry I haven't been more help in this process.  After I filed this enhancement
request, I had some unexpected fire drills that I had to take care of at work.  

Yesterday, when I swapped the new rc1 with the custom version we were previously
using, some tests failed.

I spoke with nairb774 offline.  He said 

"
Seems there is a class visibility problem…

org.mockito.internal.progress.NewOngoingStubbing<T> is not exposed via OSGi, yet
org.mockito.Mockito.when(T) returns an instance of this type.  Either this 
package
should be exported (easiest solution) or the interface needs to move to an 
exported
package.
"

It looks like this is related to issue 92.
http://code.google.com/p/mockito/issues/detail?id=92

Original comment by lukewpat...@gmail.com on 11 Jun 2009 at 2:05

[GoogleCodeExporter]

Thanks a lot for reporting it! OngoingStubbing will go to exported package.

Reopened the enhancement

Original comment by szcze...@gmail.com on 11 Jun 2009 at 2:19

• Changed state: Accepted

[GoogleCodeExporter]

Question to OSGi guys.

In order to be consistent with current dual distribution model, e.g. 
mockito-core &
mockito-all, does it make sense to have 2 osgi bundles: mockito-core & 
mockito-all?

Thanks for info

Original comment by szcze...@gmail.com on 16 Jun 2009 at 8:16

[GoogleCodeExporter]

Good question.

Personally, I would only ever use mockito-core.  I use a build system (Maven) 
that
pulls in transitive dependencies anyway (and to me it seems more pure to keep 
the
other projects separate).  The only complication is that Hamcrest has been 
hesitant
to OSGi-ify their project.  Objenesis has completed the process, but hasn't yet
released with the changes.

Until Hamcrest is OSGi-ified (if it ever is), some consumers might want to 
consume
mockito-all.

So I guess both might be needed.

Original comment by lukewpat...@gmail.com on 16 Jun 2009 at 8:32

[GoogleCodeExporter]

>Personally, I would only ever use mockito-core.  I use a build system (Maven) 
that
>pulls in transitive dependencies anyway (and to me it seems more pure to keep 
the
>other projects separate).  The only complication is that Hamcrest has been 
hesitant
>to OSGi-ify their project.  Objenesis has completed the process, but hasn't yet
>released with the changes.

It shows one more issue. The pom that gets deployed with mockito-core has 2
dependencies: hamcrest & objenesis. Therefore we should probably change those
dependencies to use springsource's OSGI-ied bundles. Unfortunately, 
springsource's
hamcrest/objenesis are not in maven central :(

Original comment by szcze...@gmail.com on 16 Jun 2009 at 9:03

[GoogleCodeExporter]

> It shows one more issue. The pom that gets deployed with mockito-core has 2
> dependencies: hamcrest & objenesis. Therefore we should probably change those
> dependencies to use springsource's OSGI-ied bundles. Unfortunately, 
springsource's
> hamcrest/objenesis are not in maven central :(

Exactly.  That gets to the heart of this issue, especially with regards to 
Maven/OSGi
consumers.  

IMO the best course of action is to leave the dependency coordinates as they 
are. 
Current mockito dependency tree consumers wouldn't be any worse off than they 
are
now.  When hamcrest and objenesis are ready, the mockito pom will be ready.

Original comment by lukewpat...@gmail.com on 16 Jun 2009 at 9:37

[GoogleCodeExporter]

I would leave them pointing to things that are in maven central.  Others may 
think
differently (but neither way is the end of the world if it turns out to be the 
wrong
choice).  I, as a maven user also, can play games to make the bundles resolve
correctly.  It is not pretty, but it works.  Hopefully, Luke and I can get 
Hamcrest
to implement the changes then everyone will be back on the easy path again.

Sorry about dropping the ball on helping out. ~Brian

Original comment by nairb...@gmail.com on 16 Jun 2009 at 9:40

[GoogleCodeExporter]

Oh right guys, thanks a lot for the feedback. I'm going to keep pom's 
dependencies as
they are now.

Original comment by szcze...@gmail.com on 16 Jun 2009 at 9:44

[GoogleCodeExporter]

>Sorry about dropping the ball on helping out. ~Brian

That's ok, thanks for your help anyway!

Last question I have for you is about the bundle name. Previously, the name was:
"org.mockito". I changed the build so that it produces 
"org.mockito.mockito-all" and
"org.mockito.mockito-core". Is this the correct way of naming bundles according 
to osgi?

Original comment by szcze...@gmail.com on 17 Jun 2009 at 11:46

[GoogleCodeExporter]

Once you get under "org.mockito" you have free reign just like Java packages.  
The
only thing I had to check was if '-' was a valid character.  By the 
specification [1]
'-' is a valid character.  So, yes you can name them that and correct is up to 
you. 
I don't know of any other conventions that have come out.

Good call on the different names - I did not think of that.

[1] http://www.osgi.org/download/r4v41/r4.core.pdf (Section 3.5.2 & 1.3.2)

Original comment by nairb...@gmail.com on 17 Jun 2009 at 2:10

[GoogleCodeExporter]

> I changed the build so that it produces "org.mockito.mockito-all" 
> and "org.mockito.mockito-core".

Since they both can't be the same as the root package, those names make good 
sense. 
Regarding the '-', I've produced bundles before that contain '-'s.

${groupId}.${artifactId} makes intuitive sense from a Maven and uniqueness 
point of view.

Original comment by lukewpat...@gmail.com on 17 Jun 2009 at 3:19

[GoogleCodeExporter]

Oh right. Thanks for info!

I'm closing this one as it is fixed in trunk.

Original comment by szcze...@gmail.com on 17 Jun 2009 at 6:52

• Changed state: Fixed

[GoogleCodeExporter]

Sorry, I should have tested from trunk before you got rc2 out.

When I tested with mockito-all rc2, I get:

!ENTRY org.eclipse.osgi 2 0 2009-06-25 10:15:15.665
!MESSAGE One or more bundles are not resolved because the following root 
constraints
are not resolved:
!SUBENTRY 1 org.eclipse.osgi 2 0 2009-06-25 10:15:15.666
!MESSAGE Bundle 
initial@reference:file:plugins/org.mockito/mockito-all-1.8.0-rc2.jar/
was not resolved.
!SUBENTRY 2 org.mockito.mockito-all 2 0 2009-06-25 10:15:15.666
!MESSAGE Missing imported package org.hamcrest.internal_0.0.0.
!SUBENTRY 2 org.mockito.mockito-all 2 0 2009-06-25 10:15:15.666
!MESSAGE Missing imported package org.objenesis_0.0.0.

So it looks like mockito-all should export the hamcrest and objenesis packages, 
since
it is in actuality providing them to consumers.

I looked at the OSGI-ified mockito-all v1.7 that is in use by another team at my
company.  They had to export these packages:
org.hamcrest,
org.hamcrest.core,
org.hamcrest.internal,
org.objenesis,
org.objenesis.instantiator,
org.objenesis.instantiator.basic,
org.objenesis.instantiator.gcj,
org.objenesis.instantiator.jrockit,
org.objenesis.instantiator.sun,
org.objenesis.strategy

Thanks for your willingness, efforts and patience in adding this enhancement.  

I attached a pretty-format copy of the current MANIFEST.MF, for reference.

Original comment by lukewpat...@gmail.com on 25 Jun 2009 at 3:59

Attachments:

• pretty-format-rc2-MANIFEST.MF

[GoogleCodeExporter]

Sorry, I didn't see your comment. Googlecode sucks and sometimes doesn't send 
the
notifications (my last project on googlecode). Will fix it.

Original comment by szcze...@gmail.com on 23 Oct 2009 at 6:39

[GoogleCodeExporter]

Issue 92 has been merged into this issue.

Original comment by szcze...@gmail.com on 11 Nov 2009 at 2:39