-
Notifications
You must be signed in to change notification settings - Fork 19
Description
I use modello fairly often. But ffor years, I have never successfully gotten the snakeyaml-*
plugins to work for me. I've tried several times with several versions of the plugin and the parser library, so I thought I'd give it a try modello-2.x
.
The plugin produces generated code [for me] that won't compile with any 2.0+
version of snakeyaml
. I ran an integration test build on a checkout of modello-2.1.2
, and there appear to be no generated test executions for snakeyaml
. Without such test executions, it seems reasonable that API changes would get missed.
Numerous issues exist within my generated code, such as
- Snakeyaml's
Parser
constructor (inParserImpl
) requires aLoaderOptions
object to use aReader
. Other options were@Deprecated
at least as ofsnakeyaml-1.33
. Adding a defaultnew LoaderOptions()
there would probably solve this. - SequenceStartEvent's constructor does not have the signatures used by the generated files. In 2.x, the
SequenceStartEvent
has a constructor whose last argument is aDumperOptions.FlowStyle
, not aboolean
. Also deprecated in 1.33.
PROBABLY should beFlowStyle.BLOCK
. Java5
-basedMap
models (which gen as<String,String>
) are processed as<String,Object>
which cannot be compiled due to mistyping- The plugin generates this line for the Map
for ( java.util.Map.Entry<String, String> entry : generatedProcessExecution.getExy().entrySet() )
where.getExy()
returns aMap
which is<String,Object>
which the compiler (correctly) reports as
cannot convert from element type Map.Entry<Object,String> to Map.Entry<String,String>
- The plugin generates this line for the Map
The relevant <field>
in my model for exy
(above) is
<field>
<name>exy</name>
<description>Extra vocabulary as key/value.</description>
<version>1.0.0+</version>
<identifier>true</identifier>
<type>Map</type>
<association xml.mapStyle="inline">
<type>String</type>
<multiplicity>*</multiplicity>
</association>
</field>
If I fall back to snakeyaml-1.33
, then the only failure is the <String,Object>
relative to the Map
field. Even if that weren't the case, this would not be parity with modello-2.1.2
's listed dependencies.
If I'm configuring something incorrectly that's triggering some of this, I'd love to hear what that is.
Attaching my model for reference.