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 Tue, 06 Jun 2017 01:14:13 GMT
Really glad that you have dug into this work. Felt a bit lonely for a
while... :-D


Below is a model.json file that I have been using to get additional bits
and pieces working beyond the bare bone skeleton. Feel free to use as a
starting point for some more elaborate generations.


{
  "name": "Flood",
  "packageName": "com.sensetif.sink",
  "applicationtype": "Rest API",
  "features": [
    "jmx",
    "security"
  ],
  "entitystore": "Cassandra",
  "indexing": "Rdf",
  "caching": "Memcache",
  "metrics": "Codahale",
  "modules": {
    "user": {
      "cruds": [
        {"name": "User"},
        {"name": "Users" },
        {"name": "Role"},
        {"name": "Roles"},
        {"name": "Permission"},
        {"name": "Permissions"},
        {"name": "Group"},
        {"name": "Groups"}
      ],
      "services": [
        {
          "name": "AuthService",
          "visibility": "application",
          "configuration" : [
            { "name": "backend", "type": "java.lang.String",
"default": "ldap", "description": [ "Type of backend authentication
and authorization system" ] },
            { "name": "connectString", "type": "java.lang.String",
"description": ["The connection string to the authentication and
authorization backend system."] }
          ]
        }
      ],
      "plainTypes": [
        { "name": "AuthBackend", "type": "enum", "values":
"ldap,kerberos,entitystore" }
      ]
    },
    "organization": {
      "cruds": [
        {
          "name": "Organization",
          "properties": [
            { "name": "name", "type": "java.lang.String" },
            { "name": "created", "type": "java.time.Instant" }
          ]
        },
        { "name": "Project" },
        { "name": "Contract" },
        { "name": "ContractPart" },
        { "name": "Order" },
        { "name": "OrderConfirmation" },
        { "name": "Invoice" }
      ],
      "entities": [
      ],
      "values": [
        {
          "name": "CreditLimit",
          "properties" : [
            { "name" : "amount", "type" : "java.math.BigDecimal" },
            { "name" : "currency", "type" : "java.lang.String" }
          ]
        },
        { "name": "Label" }
      ],
      "transients": [
        { "name": "PaypalNotification" }
      ]
    },
    "sensor": {
      "cruds": [
        { "name": "SensorDetails",
          "properties": [
            { "name": "name", "type": "java.lang.String" },
            { "name": "location", "type": "java.lang.String" },
            { "name": "description", "type": "java.lang.String" }
          ],
          "associations": [
            { "name": "project", "type":
"com.sensetif.sink.model.organization.Project" }
          ],
          "manyassociations": [
          ]
        }
      ],
      "entities": [
        { "name": "SensorPoll" },
        { "name": "Access",
          "properties": [
            { "name": "type", "type":
"com.sensetif.sink.model.sensor.AccessType"},
            { "name": "address", "type":
"com.sensetif.sink.model.sensor.Address"},
            { "name": "selector", "type":
"com.sensetif.sink.model.sensor.Selector"}
          ]
        }
      ],
      "plainTypes": [
        { "name": "AccessType", "type": "enum" },
        { "name": "Address", "type": "interface" },
        { "name": "Selector", "type": "interface" }
      ],
      "values": [
        { "name": "JsonDocumentAddress" },
        { "name": "XmlDocumentAddress" },
        { "name": "ModbusDeviceAddress" },
        { "name": "JsonPathSelector" },
        { "name": "XPathSelector" },
        { "name": "ModbusSelector" },
        { "name": "PollSchedule" }
      ]
    }
  }
}


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

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


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

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