JAMES-3140 Add a per server testing builder

[chibenwa]

It hides the generic typing complexity of the JamesServerBuilder
and addresses testing configuration duplication while still exposing
module combination configuration in every test.

[rouazana]

seems nice

[chibenwa]

MemorySpamAssassinContractTest.imapMovesToSpamMailboxShouldBeConsideredAsSpam » ConditionTimeout

test this please

[mbaechler]

I fail to see what's the point of this PR. It looks like a builder call extraction (anti-pattern ?) dealing with a single type of Server.
What do we gain?

[chibenwa]

[da18061a9736f5e08949686b163f8a404a5584dc] [ERROR]   MailboxesRoutesTest$FixingReIndexing$TaskDetails.userReprocessingShouldReturnTaskDetailsWhenFailingAtTheMailboxLevel:1304 1 expectation failed.
[da18061a9736f5e08949686b163f8a404a5584dc] JSON path status doesn't match.
[da18061a9736f5e08949686b163f8a404a5584dc] Expected: is "failed"
[da18061a9736f5e08949686b163f8a404a5584dc]   Actual: null

Fixed elsewhere.

test this please

[chibenwa]

I fail to see what's the point of this PR. It looks like a builder call extraction (anti-pattern ?) dealing with a single type of Server.
What do we gain?

#3531 (comment) explains this.

The team tend to like this proposal.

[mbaechler]

I fail to see what's the point of this PR. It looks like a builder call extraction (anti-pattern ?) dealing with a single type of Server.
What do we gain?

#3531 (comment) explains this.

The team tend to like this proposal.

Ok, let's ask more precise questions

It hides the generic typing complexity of the JamesServerBuilder

What typing complexity? In this PR it's always used with a single type, right?

and addresses testing configuration duplication while still exposing module combination configuration in every test.

I understand it puts in common these 3 lines :

                .workingDirectory(tmpDir)
                .configurationFromClasspath())
                .build());

does it do more that than?

[chibenwa]

does it do more that than?

It turns:

new JamesServerBuilder<CassandraRabbitMQJamesConfiguration>(...)

Into

TestingDistributedJamesServerBuilder.

Which is simpler.

As we might get more options in the future, we could add staged builders to make writing integration test easier.

[mbaechler]

does it do more that than?

It turns:

new JamesServerBuilder<CassandraRabbitMQJamesConfiguration>(...)

Into

TestingDistributedJamesServerBuilder.

Which is simpler.

Are you arguing List is simpler than List<Foo>? Or that ListInt is simpler than List<Integer>?

Sorry, I don't buy that.

As we might get more options in the future, we could add staged builders to make writing integration test easier.

What about just making the real server builder good enough that we don't need another layer to abstract it?

[chibenwa]

What about just making the real server builder good enough that we don't need another layer to abstract it?

Sounds hard.

The server builder (generic) don't know which configuration builder to be using (specific)

Suggestions?

[mbaechler]

What about just making the real server builder good enough that we don't need another layer to abstract it?

Sounds hard.

The server builder (generic) don't know which configuration builder to be using (specific)

Suggestions?

Nested builders.

DistributedJames.builder().generic(builder -> builder.foo().bar()).specific1().build();

[chibenwa]

Nested builders.

Sorry, we end up with something specific anyway, I don't see how it differ from what is proposed here.

[chibenwa]

See #3568