@openstack4j/reviewers, review would be highly appreciated.

@pjdarton, I tried to stay from whitespace changes but some of the files ware badly messed (three space indent, tabs mixed with spaces) so I gave up at places. There ware no intent to rectify the bed formatting. I track that effort in https://github.com/openstack4j/openstack4j/projects/1. /** {@inheritDoc} */ falls into the category of useless javadoc as that is what javadoc would do anyway.

My only comments w.r.t. functionality are that NeutronFloatingIP.toString() no longer includes the tenantId field and now includes a \n. Given that we're calling omitNullValues() I think it'd be better to include all fields and, personally, I'm not a fan of embedded \n characters in toString methods - if a caller wants a linebreak then that's their business and it's trivial to add, whereas taking things away is more complicated.

100% agreed, mind the \n is being removed, not added. w.r.t. s/tenantId/projectId/, they are the same as the way I understand that, OS is switching terminology from tenant to project. So both getters are present not to break API for clients, but I saw no purpose to print both fields in toString when their value is guaranteed to be the same - so I chose to stick with modern naming.

I believe that adding new fields that go unused by client code will have no effect because null values don't get written into the json

Correct, I have verified that. One nasty thing about the openstack4j design is, the same object are often used for sending and receiving the entity even though the fields documented on GET and POST do not always 100% match (revision_number is read only, etc.).

but I'd hope that these fields are (a) correctly spelled

oh, are they not?

Lastly, I'd recommend adding a description to the PR

Valid point. My apology.

😁 Yeah, I have similar tendencies myself - a near-uncontrollable need to tidy up messy code as I go along - the problem with that is that those changes then make the main changes harder to see. That's why I prefer to keep functional changes in PRs that have no other others, and tidy-up/refactor PRs to have no functional changes.
What I generally end up doing is making a "combined" set of changes, then submitting a change that's just the non-functional stuff, get that merged in, and then rebase the "combined" one so it's just the minimal set of changes required to change the functionality.
...or I lose patience with the duff code entirely, park my "proper work" and tidy it all up before going back to what I was originally trying to do 😉

the \n is being removed, not added

Ok, my bad; I'm glad the \n is gone now 😁

s/tenantId/projectId/

If they're separate fields, they're not guaranteed to be the same value - a user could set them to different values.
I'd suggest that we do one of two things:
a) Force them to be the same by putting extra code in the getters/setters
b) Have the toString field show both if they're different but only the new name otherwise.

correctly spelled ... are they not?

I hadn't checked; I'd not looked up the spec when I first reviewed the code.
As you've since added a description and a link to the spec, I've since checked.
The spelling looks right ... but personally I'd prefer the fields to be in the code in the same order they are in the spec (or in alphabetical order).
I noticed that qos_policy_id isn't explicitly listed in either the JSON request or response - presumably there's some magic whereby the QoS extension adds this attribute into specific (but unspecified) requests/responses?

@pjdarton, good idea with the tenantId. Updated.

Re reformatting all the code and property reordering, I prefer to keep the code changes conservative since the fork day to simplify eventual merging back. In fact, we are having discussions with past maintainers of ContianX/openstack4j to move beck there taking advantage of existing .org domain, continuation of maven coordinates and the fact most users are filing issues and PRs there. Once we merge or we get clear that we won't, I am happy to do that.

Ah, if we're planning on merging back then, yes, I agree that we should keep our code changes as simple as possible.
...but if we're doing that, I'd suggest that it's even more important that we avoid all unnecessary changes, e.g. the whitespace/formatting changes, in any functional-change PR.

Thanks for the review, @pjdarton. We are in agreement, I hope we will be able to get rid of the messed formatting soon.