Add peekError and peekSuccess methods

[marcindabrowski]

Thanks for the library! It is helpful but I found that it lacks two methods that can improve the fluency of its usage.

peekError and peekSuccess methods can be used to consume success or error values and proceed with the same result.

Currently, to do the same logic as peekSuccess I have to use flatMap method that returns Result with success value that will be discarded.

I also corrected some spell check issues found by IntelliJ.

I didn't found how information about how to contribute, so I just run tests and checkstyle.
I would be great if you could add something, and add maven goal for automatic formatting.

[sviperll]

Thank you very much for the contribution!

I've added a comment about the naming. I think on{Error,Success} may look too implicit, I propose to name those peek{Error,Success}.

I also corrected some spell check issues found by IntelliJ.

Thanks!

I didn't found how information about how to contribute, so I just run tests and checkstyle.
I would be great if you could add something, and add maven goal for automatic formatting.

I think what you've done is the intended process. Can you maybe share what you'd like to see? Something like CONTRIBUTING-file? Do you have an example that you think is good to take as an example to follow?

[marcindabrowski]

Updated the PR.

I think you can add pull request template for your repository.

I would be nice if you also add information about Java used for building - I checked the manifest file from distribution jar and found that it was build with 21.

And I would be great to have some GitHub actions that runs all checks - I can help with that, just tell me what checks from maven has to be run.

[marcindabrowski]

And may I ask why you are not following Semantic Versioning?

[sviperll]

I think you can add pull request template for your repository.

Ok, I'll try to do it.

I would be nice if you also add information about Java used for building - I checked the manifest file from distribution jar and found that it was build with 21.

I may add this to the README and to the maven-description to be more discoverable.

And I would be great to have some GitHub actions that runs all checks - I can help with that, just tell me what checks from maven has to be run.

I think we should run mvn verify. I would appreciate if you add a github-action.

And may I ask why you are not following Semantic Versioning?

What do you mean by this? There is only one version, how can I not follow semantic versioning?

I think the answer to most of your questions is that I do not have much time for maintenance and such a small library, like this one shouldn't require a lot of maintenance. I would gladly accept any contributions though.

[marcindabrowski]

Thanks for merging.

And may I ask why you are not following Semantic Versioning?

What do you mean by this? There is only one version, how can I not follow semantic versioning?

Semantic versioning assumes that library version is build using at least this: MAJOR.MINOR.PATCH.
And you released 1.0 not 1.0.0. And this is why I asked.

When you will release next version? Can you do it today/tomorrow? I would appreciate it.

GitHub action I will add at the evening or tomorrow.

[sviperll]

When you will release next version? Can you do it today/tomorrow? I would appreciate it.

Will do. Probably tomorrow morning.

[sviperll]

I've release your changes. You can use the new 1.1.3 version.