polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: yeoman-work back to develop
Date Mon, 05 Jun 2017 16:38:10 GMT
Yeah, good point... I will fix that asap.

On Tue, Jun 6, 2017 at 12:13 AM, Paul Merlin <paulmerlin@apache.org> wrote:

> 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.
>>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message