bytebuddy plan

[Szczepan Faber]

Hey guys,

I intend to push mockito-bytebuddy integration into a separate Gradle
subproject.

1. It will be released separately to maven central as
'org.mockito:mockito-bytebuddy'
2. It will share the same version as the main artifact, 'mockito-core'
3. mockito-core artifact will declare dependency on
'org.mockito:mockito-bytebuddy'

Thoughts?

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

[Brice Dutheil]

• So no integrated mockmaker for 2.0 ?
• Will bytebuddy be shaded in this artifact ?
• Just a remark we may have to revise how such components are tested ?

— 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, I think it needs to be shaded. I still think about it, unsure how
to best proceed. It's getting complicated to ship multiple jars.

[Brice Dutheil]

It’s getting complicated to ship multiple jars.

hell yeah :)

​

-- Brice

[Szczepan Faber]

Ok, it's too much work to release separate jars automatically :) It
would push 2.0.0 release by months, most likely. Here's my current
plan, let me know your thoughts.

Here's the incremental plan:

The first 2.* release will be 2.1.0 (there will be no 2.0.0 due to the
rather awkward beta naming convention I have invented)

a) mockito-core:2.1.0 -> bytebuddy // no shading, direct dependency
on byte buddy
b) mockito-core:2.2.0 -> mockito-bytebuddy:2.2.0 -> bytebuddy // no
shading but there is a separate jar that contain bytebyddy integration
c) mockito-core:2.3.0 -> mockito-bytebuddy:2.3.0 // bytebuddy
dependency only at build-time, shaded at runtime

At some point, potentially:

d) mockito-cglib:2.*
e) mockito-core:2.x.0-java8 // appending java8 to version instead of to the name
f) mockito-core -> mockito-api + mockito-bytebuddy

For 2.0, I think we need only a). We might do e) to make users happy.

Cheers!

[Marcin Zajączkowski]

On 2015-07-07 07:32, Szczepan Faber wrote:
> Ok, it's too much work to release separate jars automatically :) It

Do you mean separate jars from submodules or separate jars with
different versions for Java7 and Java8 from different branches?

> would push 2.0.0 release by months, most likely. Here's my current
> plan, let me know your thoughts.
>
> Here's the incremental plan:
>
> The first 2.* release will be 2.1.0 (there will be no 2.0.0 due to the
> rather awkward beta naming convention I have invented)

You invented and I supported ;). Hopefully there is @MariuszS among the
list subscribers to warn us against further mistakes :).

> a) mockito-core:2.1.0 -> bytebuddy // no shading, direct dependency
> on byte buddy
> b) mockito-core:2.2.0 -> mockito-bytebuddy:2.2.0 -> bytebuddy // no
> shading but there is a separate jar that contain bytebyddy integration
> c) mockito-core:2.3.0 -> mockito-bytebuddy:2.3.0 // bytebuddy
> dependency only at build-time, shaded at runtime
>
> At some point, potentially:
>
> d) mockito-cglib:2.*
> e) mockito-core:2.x.0-java8 // appending java8 to version instead of to the name

I'm not a versioning expert, but it would probably make it unable to use
version range in pom.xml/build.gradle like [2.0.0,3.0.0) for people
using Java 7 (a question could be how many people uses it in practice?).
AFAIR in addition there was the idea to have a separate branches for
Java 7 and 8 (which turned out a must in case of AssertJ - it was
impractical (impossible?) to keep the same core API and only add a
separate module with Java8 extensions).

On the other hand I initially didn't like the idea with versions 2.0 and
3.0 in AssertJ - it may be confusing. Nevertheless assuming that Mockito
2.x would be the last version line with support for Java <8 it makes it
quite easy to continue with further 3.x and 4.x releases.

@MariuszS, being a versioning expert, what threats do you see in various
versiong schemes?

Sorry for not being too constructive and only point out potential problems.

Marcin

http://blog.solidsoft.info/ - Working code is not enough

[Brice Dutheil]

OK for point a, b, c

Regarding 

> e) mockito-core:2.x.0-java8 // appending java8 to version instead of to the name

A version 3.x will be better for version range, development wise (this could be the `master`), but older version could be branched out (`version/2.x`) in case of fixes.

> f) mockito-core -> mockito-api + mockito-bytebuddy

I'm not a big fan of splitting again mockito in several smaller dependencies

-- Brice

[Szczepan Faber]

Thanks for feedback!

>Do you mean separate jars from submodules or separate jars with
>different versions for Java7 and Java8 from different branches?

Both ;)

>only add a separate module with Java8 extensions

This might be possible, imagine a Mockito8 class, etc. However, I
don't want to go down this path because it seems to trigger
significant API duplication and possibly confusing.

> A version 3.x will be better for version range, development wise (this could
> be the `master`), but older version could be branched out (`version/2.x`) in
> case of fixes.

+1

I like it. So 2.x for java5 compatibility and 3.x for java8. I really
want to avoid creating yet another module name (like mockito-java8).
There will be just mockito-core. Effectively this means that there
will be no major version release for java5 compatibility ever again. I
think this is ok given Mockito 1.x has been around for 7 years :)

hamcrest entertained the idea of putting java version in front, e.g.:
mockito-core:8.x would be java8 compat. Seems inflexible and
potentially confusing.

> I'm not a big fan of splitting again mockito in several smaller dependencies

Any specific reason? Options b/c already do this.

Cheers!

[Brice Dutheil]

hamcrest entertained the idea of putting java version in front, e.g.: mockito-core:8.x would be java8 compat. Seems inflexible and potentially confusing.

Agreed let’s not do that, 3.x is ok imho.

So 2.x for java5 compatibility and 3.x for java8.

Yes

I’m not a big fan of splitting again mockito in several smaller dependencies

Any specific reason? Options b/c already do this.

Extracting the Mockmaker seems a good idea as it is a pluggable component. But I wouldn’t split mockito any further. I don’t think it brings significant value for a test related jar.
Also it may lead to some DependenciesDeclarationOverflowDeveloperError.

— Brice

[Szczepan Faber]

> DependenciesDeclarationOverflowDeveloperError

:)

+1 I want developers to only declare dependency on mockito-core and
everything works.

> Extracting the Mockmaker seems a good idea as it is a pluggable component

If there is a direct dependency from mockito-core to mockito-bytebuddy
then they are coupled (which is ok for the time being). Let's go with
this approach after 2.1.0 final and reevaluate if needed.

Cheers!