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:48:23 GMT
Le 2017-06-05 18:38, Niclas Hedhman a écrit :
> Yeah, good point... I will fix that asap.

I had the change handy so I pushed it.



./gradlew :tools:generator:npmTest

BUILD SUCCESSFUL

Total time: 7.118 secs



That is with the docker tests.

\o/

The 
tools/generator-polygene/build/reports/tests/npmTest/generator-polygene.xml 
JUnit formatted test report is handy.
It lacks captured test output but it's better than nothing.


./gradlew :tools:generator:npmTestAll

... running ... it may take a while, I may also just kill it at some 
point :)




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


Mime
View raw message