status of bytebuddy integration

[Szczepan Faber]

Hey guys,

Thanks for the great work on byte buddy!!!

1. Can we completely delete cglib support along with the code? (I
would love to do this)

2. Do we need to shade the mockmaker? Mockito depends on 0.* version
of bytebuddy and according to semver, pre. 1.0 versions are allowed to
include breaking changes. I would prefer mockito to continue working
correctly when user has a different version of bytebuddy on his
classpath. In past, even if cglib was used by other libraries (even if
the version was consistent) it caused problems due to class caching.

3. Is there a particular reason bytebuddy mock maker code lives in a
separate source set?

4. I'm wondering if we should introduce a new jar, called
mockito-basic (or mockito-base, mockito-thin, etc.). It would not have
any opinionated settings like bytebuddy mock maker. mockito-core would
depend on mockito-basic + mockito-bytebuddy. Thoughts?
Down the road we could also extract mockito-injection, mockito-junit,
mockito-hamcrest, mockito-testng etc.

Cheers!
--
Szczepan Faber
Founder mockito.org; Core dev gradle.org
tweets as @szczepiq; blogs at blog.mockito.org

[Brice Dutheil]

Yes bytebuddy is fully operational and performing better. Though it should be shaded imho, I don’t know how to do it with gradle. I wanted to shade objenesis as well, as it’s used by a lot of project nowadays (spring being the most used)

There’s still some unknown area, like OSGI.

I’d like to keep CGLIB code as an external mockmaker. That’s why I kept the lib and code in the repo. Also it may be needed for Powermock folks. And it could show how a mockmaker could be actually done. Separate source dir was first thought as a way to release bytebuddy mockmaker separately (for example for mockito 1.x users)

IMHO and many people I’ve been involved with is mockito is good as it is nowaday: ie. you don’t have to declare yet another (mockito) dependency

​

-- Brice

--
You received this message because you are subscribed to the Google Groups "mockito-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mockito-dev...@googlegroups.com.
To post to this group, send email to mocki...@googlegroups.com.
Visit this group at http://groups.google.com/group/mockito-dev.
For more options, visit https://groups.google.com/d/optout.

[Szczepan Faber]

>Yes bytebuddy is fully operational and performing better.

Cool, cool :)

>Though it should be shaded imho, I don’t know how to do it with gradle

+1

>I wanted to shade objenesis as well, as it’s used by a lot of project nowadays (spring being the most used)

-1. unshaded objenesis never failed us so far. I'm feeling lucky :)

>There’s still some unknown area, like OSGI.

Let's not worry too much about OSGi, I will remove the ugly ant code that does the current OSGi stuff and replace it with native gradle. I expect user reports that 2.* does not work correctly. We will fix this after 2.0 final.

>I’d like to keep CGLIB code as an external mockmaker.

You mean external jar? +1

>eparate source dir was first thought as a way to release bytebuddy mockmaker separately (for example for mockito 1.x users)

Ok. Do you mind if I move it to src?

>IMHO and many people I’ve been involved with is mockito is good as it is nowaday: ie. you don’t have to declare yet another (mockito) dependency

I agree. mockito-core should provide all the good defaults and no other jars are needed. However, when someone wants different mockmaker, he can declare dependency on mockito-base and mockito-cglib. Thoughts?

Cheers!

[Brice Dutheil]

I’d like to keep CGLIB code as an external mockmaker.

You mean external jar? +1

Yes as an external jar

eparate source dir was first thought as a way to release bytebuddy mockmaker separately (for example for mockito 1.x users)

Ok. Do you mind if I move it to src?

Nope

I agree. mockito-core should provide all the good defaults and no other jars are needed. However, when someone wants different mockmaker, he can declare dependency on mockito-base and mockito-cglib. Thoughts?

Yes that’s the idea. A mockmaker is somehow an override of the mockito good defaults.

— Brice

[Szczepan Faber]

Do we want to ship mockito-core with cglib mockmaker? I'd rather not...

On Tue, Jun 30, 2015, 14:30 Brice Dutheil <brice....@gmail.com> wrote:

[Brice Dutheil]

Do we want to ship mockito-core with cglib mockmaker?

Nope :)

​

-- Brice

[Szczepan Faber]

+1