Missing mapping for some Issue API response items

[francton14]

The ff. Redmine API response items are not being mapped or ignored in the current implementation.

1. actual_start_date
2. actual_due_date

May I ask if the above fields be included in the mapping of the API response to an Issue bean?

[alexeyOnGitHub]

my recommendation would be to submit this suggestion on redmine.org forum and see if anyone wants to contribute to this library.

[francton14]

Thanks for the quick reply @alexeyOnGitHub.

Would it be okay if I create a PR to update the above mentioned bean?

Edit:
I really need the above items in the application I am building. As a temporary fix, I've pulled the source of the latest stable build and modified it to add support for said fields. Of course, I would certainly want the changes to be included in the official release if possible.

[alexeyOnGitHub]

sure, please include some tests demonstrating that the fix works.

[francton14]

I've filed a PR containing the changes/updates I've made. Please check the ff. link.
365

[francton14]

Just a question, would it still be possible to introduce the same changes to v3?
My project still uses Java 8 and I noticed that master needs to Java 11 to compile.
Not really an expert regarding this matter but I've tried compiling master to a JAR and manually added it to my project and my project would fail to start due to the java version of the JAR.
However, V3 does work properly.

[alexeyOnGitHub]

my recommendation would be to migrate to Java 14+ at this point if at all possible. Java 8 has been EOL for years now.
I don't mind if this gets into 3.x branch, but I would prefer someone from redmine.org to drive this - review, test with various redmine versions, approve the PR, etc. I do not use Redmine anymore and I cannot afford proper testing and reviews for this project at this point.

[stolp]

@alexeyOnGitHub Regarding EOL for Java 8, please see my comment on #353
It is in still under active maintenance until 2022, Commercially it is supported until 2030.

Besides, I can understand that you can not give the project full attention and appreciate your ongoing involvement.
Thank you for that.

@francton14 Changes are good that 4.0.x is still building against Java with minor modifications to the build setup.
@alexeyOnGitHub Would you accept patches to rollback the required runtime dependencies to Java 8 for 4.0.x?

[alexeyOnGitHub]

@stolp if some Redmine team wants to take over this library, they are welcome to make whatever changes they feel right - remove Java 11, drop the fluent-style API and get back to the old style, etc. it is hard for me to imagine requirements for this library if I no longer actively use it.

just out of curiosity - what is the reason that is stopping you from migrating your projects to at least JDK 11? it should be available on all platforms, and its backward compatibility is pretty good.
would it be practical to spend some time migrating the remaining project(s) to Java 11+ (I would suggest Java 14 actually, at least for better NPE handling) - instead of pushing various dependencies back into JDK8 world?

[stolp]

@alexeyOnGitHub I finally took the step from migrating my project to Java 11 a few months ago, so I currently have no personal stake in a backport to Java 8. This product now depends on over 350 other external libraries, so a runtime migration had to be a huge planned effort. Although it may possible easier next time, I am not eager to go to next LTS (17) any time soon.

Being through this, I can feel the pain others like @francton14 may have to go through porting their projects just because a downstream library decided to up their requirements.

The friendliest way for utility libraries is to keep their own runtime requirements as low as possible to make life as easy as possible on their consumers. Look for example at the Apache Commons or Spring libraries. They typically depend on Java 8 (or sometimes even lower) but do work with later versions.

Hence my suggestion and offer to work in that direction. I just like too see this code as usable as possible for everyone. This is not the only project where I am advocating this defensive approach.