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
|