So, I took a stab at this and made some progress.
The generated tests needing Docker will now automatically be skipped if
no docker service is available.
IOW, the generated projects aren't broken anymore for people that do not
run docker.
I fixed Memcache, MongoDB, Riak, Redis, JClouds, H2SQL docker
integration.
I disabled tests in generated projects when MySQL or PostgreSQL is
involved because I couldn't get the former to work (timing issue?) and
the latter requires a custom docker image. We can fix that post 3.0.
So, in the reduced set of tests, only 2 fail now, the ones using XML or
msgpack serialization.
I think there's a hiccup with how Serialization is assembled in the
generated applications.
The generator asks for which serialization subsystem to use, json, xml
or msgpack, and assemble it in infra/serialization with an application
visibility, the infra layer is used by all other layers except 'config'.
But, what is the intent really?
All JSONMapEntityStores uses JSON, and requires a JsonSerialization
service.
RdfIndexing uses some JSON under the hood, and requires a
JsonSerialization service.
The generated projects fail to bootstrap.
Values toString() method uses the Serialization visible from the value's
module.
What happen with XML or msgpack?
It will respectively return XML or Base64 encoded binary.
The rest library assumes JSON Serialization but it should require a
JsonSerialization service explicitly.
What happen with XML or msgpack?
HTTP requests are expected in application/json but parsed as XML /
Base64 encoded binary.
HTTP responses are advertised as application/json but contains XML /
Base64 encoded binary.
In this context, a HTTP/JSON service, XML and MessagePack serializations
aren't that useful.
The rest library could be enhanced to provide XML, even binary,
representations at some point.
We could use Message Pack in the configuration Memory ES instead of JSON
to save some memory, maybe.
The user might implement e.g. a custom service that need XML or binary
serialization.
I would remove the choice of serialization from the generator for 3.0
and assemble default JSON serialization where appropriate instead. Any
objections ?
/Paul
Le 2017-06-04 11:09, Paul Merlin a écrit :
Le 2017-06-04 02:54, Niclas Hedhman a écrit :
As for Docker;
Don't forget that this is code generation and it is EXPECTED that
people
tailor it to their needs. I chose ":latest" so that we don't have to
constantly maintain the version as those dependencies are likely to
upgrade
faster than we do. It is not important whether the generated project
will
break long-term for using ":latest".
`:latest` could eventually start breaking the day after we release
3.0. We do already have the list of qualified docker images in a
central place. It's like any other dependency. "maintaining" boils
down to not repeat ourselves.
BTW, it's the same with java dependencies that are also already
duplicated in the templates. We should reuse those defined in
~/dependencies.gradle at some point. That can be post 3.0.
Docker being present is a similar thing. If you don't want Docker,
kill the
DockerRule and change to connect to the external system available
through
other means.
I think the main point is; We don't need to tailor for all possible
situations, as generated code is not 'final' in any shape, way or
form. But
perhaps the generator should "check for Docker" and don't generate a
Dockerrule and disable the test if it is not present.
Well, I get your point but I strongly think that the generated
projects should not be broken. They are if they fail to build/run. And
users will think the same way I suppose. The generated projects are
just scaffoldings yes, but getting started with a broken build (as in
not building/running) will confuse users and produce noise.
