polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: yeoman-work back to develop
Date Mon, 05 Jun 2017 16:13:16 GMT
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.


Mime
View raw message