Why got DeploymentBuilder.deploy deprecated?

Camunda 7 Topics Discussion & Questions
1

Hey guys.

I just noted that in alpha1 the deploy method got deprecated. Why?

Let’s assume that I am not interested in the result of the method - why should I use a cumbersome method called “deployAndReturnDefinitions” which looks really ugly?

Sorry, but that really harms the beauty of the API :frowning: But maybe I have missed the reason why it should definitely not be used any longer (but it looks like internally it does the same).

Thanks
Bernd

2 Likes
2

Hey Bernd,

you are right the name is not the best. Do you have a better proposal?

The deployAndReturnDefinitions replaces the old deploy method. The deploy and has no own logic, it only delegates to the new deployAndReturnDefinitions method, that’s why we marked the method as deprecated. The new method is also used from the current REST API.

Best regards,
Chris

3

But then we could keep the old method (not deprecated) - as it still works well and might the better choice if you do not care about the result. This could be reflected in the ApiDocs.

And the new method is used if you do care about the result. That would be somehow intuitive I think.

It is just totally confusing if THE deploy method of the DEPLOYmentBuilder is deprecated. Please don’t do that. I already have one slide which looks wired with either the strikedthrough deploy or the new much too long name.

PS: Unfortunately I do not know a better solution for not being able to overload the return type in Java. Sorry. Maybe you could shorten it a bit? deployWithResult()

4

Yeah you’re right perhaps this is a bit more intuitive. I will change that.

I’m not quite sure if deployWithResult will solve this problem. As a user I would expect OK the other has no result?
It is not clear what kind of result I think. But yeah I will create a Ticket for this to find a better and shorter name.

Greets,
Chris

5

But the type of result is clear via the return type of the method - isn’t it? Putting it on the method name IMHO only make sense if you can do the same thing but get different results.

I agree that this raises the expectation that the other method doesn’t have a result. And we could still add this to the ApiDoc, that it should considered so because we cannot change to void as this is a breaking change.

Great - thanks a lot!

6

What about deployWithResponse()?

It differences more clearly from deploy().

Cheers, Ingo

7