Yeah, good point... I will fix that asap. On Tue, Jun 6, 2017 at 12:13 AM, Paul Merlin <[email protected]> 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
