search

ssacher-tgm / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

mockito-all-1.8.0 OSGi headers are not correct #124

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
As can be seen in comment #30 in 
http://code.google.com/p/mockito/issues/detail?id=67 the 
current headers for 1.8.0 (mockito-all) are not correct. If you import 
org.objenesis you should 
either export it either you mark the import as optional, case when if the 
import does not get 
resolved it will be wired to the internal package available in bundle (jar).

Original issue reported on code.google.com by adreghi...@gmail.com on 16 Sep 2009 at 8:58

GoogleCodeExporter commented 8 years ago 
Ok, sounds reasonable. I'm not an expert on OSGi. We can fix it.

Original comment by szcze...@gmail.com on 17 Sep 2009 at 8:27

GoogleCodeExporter commented 8 years ago 
Excellent. Also, it will be a good practice that you specify a version for 
"org.objenesis" in export and a range in 
import.

Original comment by adreghi...@gmail.com on 17 Sep 2009 at 8:59

GoogleCodeExporter commented 8 years ago 
Cool,

Maybe you want to help us (please...)? Can get the sources and fix ant / bnd
descriptor so that the manifest is generated correctly ;-) ?

Cheers!
Szczepan

Original comment by szcze...@gmail.com on 17 Sep 2009 at 9:14

GoogleCodeExporter commented 8 years ago 
I'm already doing it. But I need some answers from you to make it correctly ;)
Can you contact me via gtalk or yahoo? my id is adreghiciu on both.

Original comment by adreghi...@gmail.com on 17 Sep 2009 at 10:38

GoogleCodeExporter commented 8 years ago 
I'm off to Kiev for the conference and won't have time till Monday. 

Igor might be able to help you regarding the build file: iczechowski@gmail.com

For OSGi stuff - you know more than me. You can always post questions to mockito
mailing list. Some guys who know OSGi a lot subscribe to this list and may 
answer.

Thanks!

Original comment by szcze...@gmail.com on 17 Sep 2009 at 12:04

GoogleCodeExporter commented 8 years ago 
No problem. Attached are the modified BND instructions. I have enough knowledge 
about OSGi ;)
My questions would be related to what versions of junit/ant/.. you know that 
mockito works with. For now I 
made some assumptions.

Original comment by adreghi...@gmail.com on 17 Sep 2009 at 12:39

Attachments:

GoogleCodeExporter commented 8 years ago 
Grrr... again I didn't see any email from googlecode that you updated this 
issue.
Luckily, I was just browsing the tickets...

Will try to merge the bnd files you sent.

Thanks a lot!

Original comment by szcze...@gmail.com on 13 Oct 2009 at 9:08

GoogleCodeExporter commented 8 years ago 
Hi,

I've got bunch of questions:

mockito-core:

>Import-Package= junit.*;resolution:=optional;version="[4.0,5.0)", \

Mockito can work even without JUnit so shouldn't we skip the version of jUnit.
MockitoJUnitRunner requires JUnit but the one doesn't have use the runner.

>org.junit.*;resolution:=optional;version="[4.0,5.0)", \

Same as above

>org.hamcrest;version="[1.0,2.0)", \

I believe Mockito can work with any hamcrest as I only pull Matcher interface 
that
was not changed in hamcrest since the beginning (i think so :)

mockito-all:

Exported:

org.hamcrest;version=1.1, \
org.hamcrest.core;version=1.1, \
org.objenesis;version=1.0

Should mockito-all export hamcrest & objenesis? I would prefer users to 
explicitly
define dependencies to libraries they use rather than rely on mockito-all? Does 
it
make sense?

Import:

COM.jrockit.reflect;resolution:=optional, \
jrockit.vm;resolution:=optional, \
sun.reflect;resolution:=optional

Why do mockito-all have import all that stuff?

Thanks a lot for your help on getting the bnd right!

Original comment by szcze...@gmail.com on 20 Oct 2009 at 7:21

GoogleCodeExporter commented 8 years ago 
Well, that is why I asked a while ago for someone to chat with as to make 
propert 
OSGi headers you must know the author intentions ;)

>mockito-core:

>>Import-Package= junit.*;resolution:=optional;version="[4.0,5.0)", \

>Mockito can work even without JUnit so shouldn't we skip the version of jUnit.
>MockitoJUnitRunner requires JUnit but the one doesn't have use the runner.

You can. But do you know for sure that if I have a junit version 3 it will work 
with 
Mockito? This means that your code (mockito) can work with this earlier version 
in 
terms of API and functionality.

The optional in the import instructs OSGi that the usage is optional. It menas 
that if 
junit is not there (so the import is not satisfied) your (mockito) bundle will 
still be 
resolved and used as long as nobody uses teh code that actually makes use of 
junit 
as the Runner.

>org.hamcrest;version="[1.0,2.0)", \

>I believe Mockito can work with any hamcrest as I only pull Matcher interface 
that
>was not changed in hamcrest since the beginning (i think so :)

It that is the case then you should not specify an lower bound for the import. 
The 
upper bound (2.0) it is kind of a safety net. Usually, a 2.0 will bean a brake 
of the API  
or even a totally different approach. So your bundle will (probably) not be 
able to 
cope with it. Again if you do think that this will not be the case, you should 
remove 
the upper bound also. 

mockito-all:

Exported:

org.hamcrest;version=1.1, \
org.hamcrest.core;version=1.1, \
org.objenesis;version=1.0

Should mockito-all export hamcrest & objenesis? I would prefer users to 
explicitly
define dependencies to libraries they use rather than rely on mockito-all? Does 
it
make sense?

Well then, what is the use of mockito-all?

Import:

COM.jrockit.reflect;resolution:=optional, \
jrockit.vm;resolution:=optional, \
sun.reflect;resolution:=optional

Why do mockito-all have import all that stuff?

Because Objenesis is using them. And because mockito-all includes Objenesis the 
code (may) fail with CNF if not imported.

Anyhow, best will be that we have a chat to settle this.

BTW, I'm really enjoying Mockito these days. Great work.

Original comment by adreghi...@gmail.com on 20 Oct 2009 at 7:46

GoogleCodeExporter commented 8 years ago 
Cool, let's chat about it. What TZ are you in?

Original comment by szcze...@gmail.com on 21 Oct 2009 at 6:46

GoogleCodeExporter commented 8 years ago 
http://www.timeanddate.com/worldclock/city.html?n=49

Original comment by adreghi...@gmail.com on 21 Oct 2009 at 8:13

GoogleCodeExporter commented 8 years ago 
szczepiq, I think I started this headache for you in issue 67, and I didn't 
follow
through as much as I should have to help.  Sorry about that.

Several different teams at my company would like this problem solved.  I've been
reading through this issue thread and I'm trying to catch up with the questions 
posed.

Perhaps a call would work best, I can set up a dial-in meeting.  I am at 
http://www.timeanddate.com/worldclock/city.html?n=405 but the meeting could be 
set to
a time convenient for you.

WDYT?

Original comment by lukewpat...@gmail.com on 22 Oct 2009 at 11:17

GoogleCodeExporter commented 8 years ago 
@lukewpatterson 

If you could set up a dial-in meeting it would be great and adreghiciu could 
also
participate. How about 11.30 or 12.00 your time? It is ~18.00 in Europe.

Original comment by szcze...@gmail.com on 23 Oct 2009 at 8:12

GoogleCodeExporter commented 8 years ago 
@szczepiq, @adreghiciu, @nairb774, 

Will this time work?
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=11&day
=3&hour=18&min=0&sec=0&p1=64&p2=136&p3=176&p4=248

Original comment by lukewpat...@gmail.com on 28 Oct 2009 at 5:43

GoogleCodeExporter commented 8 years ago 
Works for me

Original comment by adreghi...@gmail.com on 28 Oct 2009 at 5:55

GoogleCodeExporter commented 8 years ago 
yes

Original comment by nairb...@gmail.com on 28 Oct 2009 at 6:00

GoogleCodeExporter commented 8 years ago 
Guys, I cannot attend to the meeting but don't worry, I'm stepping away from 
the OSGi
stuff :) (It's already taking too much of my time and I don't think I'm a big 
fan of
OSGi)

I committed the fixes to bnd files with slight modifications to the required 
versions
of jUnit (Mockito does not require any particular version of jUnit because it 
doesn't
depend on any class from jUnit)

Please pick up the jars and test it! You can grab them from Hudson once they are
built (Hudson builds every ~30 mins I think): 
http://hudson.ramfelt.se/job/Mockito

Let me know if it works for you. 

PS. Please do the meeting if you guys believe it is useful to agree on the 
manifest.
I trust your OSGi skills :) so just tell me what else needs to be fixed in bnd 
files
to get this working.

Thanks a bunch for all your help!

Original comment by szcze...@gmail.com on 28 Oct 2009 at 11:08

GoogleCodeExporter commented 8 years ago 
I tested the Hudson build and it now works for me with OSGI, so thanks for 
fixing this!

Original comment by perh...@gmail.com on 29 Oct 2009 at 8:17

GoogleCodeExporter commented 8 years ago 
It looks like it's fixed, so the meeting might not be necessary, but if anyone 
wants
to discuss I'll be on Skype (lukewpatterson) all day.

Thanks

Original comment by lukewpat...@gmail.com on 3 Nov 2009 at 12:21

GoogleCodeExporter commented 8 years ago 
cool :)

Original comment by szcze...@gmail.com on 3 Nov 2009 at 11:59

GoogleCodeExporter commented 8 years ago 
Guys, unfortunately I have a change in schedule and I cannot attend. Yet I did 
not had 
the time to test the new osgi headers.

Original comment by adreghi...@gmail.com on 3 Nov 2009 at 2:30

GoogleCodeExporter commented 8 years ago 
@adreghiciu if you give me a green light we will release 1.8.1

cheers!

Original comment by szcze...@gmail.com on 4 Nov 2009 at 3:48

GoogleCodeExporter commented 8 years ago 
Looks good to me. Go on with releasing.

Original comment by adreghi...@gmail.com on 4 Nov 2009 at 4:13

GoogleCodeExporter commented 8 years ago 
Thanks guys for help!

@lukewpatterson sorry I didn't see your comment on the previous OSGi issue. If 
you
guys don't hear out from us when you comment on an issue it might mean 
notification
failed (or we are too lazy, you never know :). Then you probably should send an 
email
to a mailing list.

Fixed in trunk.

Original comment by szcze...@gmail.com on 5 Nov 2009 at 10:44

GoogleCodeExporter commented 8 years ago 
I tested on my team's and another team's projects, swapped out our custom 
deployments
with latest snapshot release, works fine.

Original comment by lukewpat...@gmail.com on 9 Nov 2009 at 7:28

GoogleCodeExporter commented 8 years ago

Original comment by szcze...@gmail.com on 11 Nov 2009 at 1:33

GoogleCodeExporter commented 8 years ago 
Issue 92 has been merged into this issue.

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