I will do models sync firstly, then we can define what to do with tests. Additional dumps are picked from tests executions with wireshark.

Please comment diffs tab and not single commits.

Will do so.

What about sync to 1.21 in v3.0.0? There is an appropriate open issue in 3.0.0 milestone. Should we move it to the next milestone then? WDYT?

@marcuslinke i see no sense in syncing 1.21 because it will be double work to sync 1.22 separately. I have full time to fully end 1.22 sync at this week. So i can do it for 3.0.0. I also think people already wants 1.22/1.10 features... Or i can rebase 1.22 to future version later.
Testng is bit a headache for me as i know junit better... Would it be possible to mix two test frameworks?

Ideally we should jump over the precipice by mass syncing and refactoring for existed problems and then do more frequent releases with single changes.

@marcuslinke that's terrible :(

• setters are not consistent with is* for objects.
• set* vs with
• toString() is not everywhere
• equals and hashCode() partially missing

I would suggest review/merge 1.22 by portions. Will you have time?

@KostyaSha I'm currently working on the auth refactoring and my time is mainly limited to the evening hours so we will see what I can do...

@KostyaSha We should not mix two different test frameworks. Rather switch to JUnit completely. But that would be a pain...

Regarding your suggestions

setters are not consistent with is* for objects.
set* vs with
toString() is not everywhere
equals and hashCode() partially missing

I think most of this could be fixed in the current master branch as it is not related to 1.22 API sync. Maybe we could do this later when this PR is merged?

@marcuslinke i will add tests and end this portion of 1.22 then. Will target related tests to 1.22. 1.22 didn't remove any 1.21 fields so it shouldn't cause problems for 1.21. Btw 1.21 wasn't synced in time.

PS i made custom getter/setter generators for IDEA. TODO place in some sources.
@marcuslinke how with vs set should be used?

use with when we have a builder/fluent like API, otherwise set.

Ok, fixing this and will add tests for new fields.

In theory, would you accept testng->junit if i can do it?

Sure, I would accept it but ideally it should be done after all pending changes are merged. I'm currently working on the auth refactoring which affects many test sources also...

Of course later! 🏧 i'm following existed design + partially started implementing #404 (without refactorings).

@marcuslinke am i right understand that for the same types i.e. HostConfig Container different calls return different number of available fields and reusing them under question?

I.e. https://github.com/docker/docker/blob/master/docs/reference/api/docker_remote_api_v1.22.md#list-containers
returns List<Container> but Container has many fields that never existed in this call.

IDEA getter generator uses StringUtil.capitalizeWithJavaBeanConvention (idea internal class) that produces strange matching:
field -> getter
oStype -> getoStype()
osType -> getOsType()
@marcuslinke what is in your eclipse?

Getter generator:

/**
 * @see #$field.name
 */
@CheckForNull
public ##
#if($field.modifierStatic)
  static ##
#end
$field.type ##
#set($name = $StringUtil.capitalizeWithJavaBeanConvention($StringUtil.sanitizeJavaIdentifier($helper.getPropertyName($field, $project))))
#if ($field.boolean && $field.primitive)
  #if ($StringUtil.startsWithIgnoreCase($name, 'is'))
    #set($name = $StringUtil.decapitalize($name))
  #else
    is##
#end
#else
  get##
#end
${name}() {
  return $field.name;
}

@marcuslinke am i right understand that for the same types i.e. HostConfig Container different calls return different number of available fields and reusing them under question?

I think this is not intended but rather by mistake. Maybe in the past these objects had the same fields so original contributors decided to reuse a class. But nowadays for example if we have two different HostConfig objects in different places of the API we should NOT share the same HostConfig class even when they have the same fields. We should use a base class then and inherit from it. This way we have to think about when a field is added or removed in the future.

@marcuslinke yeah... I become bit confused with information where and what is used so i'm filling javadocs everywhere.

Have to go now. We have guests this weekend....

@marcuslinke get your review, resolve few 'fixme' and merge :) I can even try squash some changes into logical commits but without PR builder that may verify all commits it would be to difficult.

@KostyaSha Hopefully I'm able to review your PR today evening.

fingers crossed guys! lets hope there will be 0.10.2 support soon :)

@KostyaSha Review finished so far. What about //Fixme annotated properties? And how to proceed in general? Should we create a 1.22 branch? I ask because of 3.0.0 release. I could release 3.0.0-RC2 and then wait for feedback or do we release 3.0.0 next? WDYT?

• I will remove FIXME for test case and keep for unknown fields,
• then i will continue and end 1.22 sync in docker-java
• will report bad docs to upstream (i already found some things and have open PR that need to be updated)
• when upstream document them, fixme will be removed and code updated.

In summary i think that docker-java should be splitted into models and porcelain API (no interfaces, ability to do serders on models) #469 (comment)

• we should create PR builds against 2 or 3 docker daemon versions (in general this can be done in 2 ways:
  -- parametrization in tests with some ExternalResource (or junit analogue) that will spin specified dind daemon and run tests against it
  -- run maven tests against daemons that already available somewhere (started looking at AWS docker service).
• i will try implement build verification for all commits in PR in my jenkins pr plugin
• Auth/pull/push tests should be profile enabled/disabled.

Imho, better 3.0.0-rc2 as many people wants newer API. (We should be more robust in future with changes).

So 3.0.0-RC2 should include this PR? Wouldn't it be better to release a version (3.0.0) that supports 1.21 rudimentary and then do a subsequent 3.1.0 with 1.22 support?

unless 3.0.0 truly supports 1.21 I would go for rc2. If you release 3.0.0 please be double sure that it works.

This pr has mostly only new fields, it doesn't change internals. So should be safe.
Plus we need fix awaitCompletion() array.

Imho, release rc2, merge this, release rc3, etc. :)as soon as i end sync i will update my reference plugin and do additional checks.

👍

merged via #488