Code generation

[mishako]

Pros

• Easier development
• Automatically enforced conventions

Cons

• Some developers are not familiar with code generation

As far as I know code generation is a pretty standard approach when parsing XML. There are maven and gradle plugins that generate JAXB classes for a given xsd schema (for example maven-jaxb2-plugin). We could use one of these plugins or we could write our own plugin. Ideally I would like to be able to add support for new tags simply by changing the xsd schema.

Same goes for JSON.

[imk]

Generating parsers and generators will be a little bit more challenging because of Android support (again), Jaxb isn't supported on Android, I think there are some ways to make it working by adding lots of libs - but that seems to be really tricky.

But generally, generating this annoying boilerplate code should be possible, i.e. with tools like xtext and xtend - personally, I haven't used these yet, just found it interesting. There are repeating patterns like read and parse a date from an element and set the corresponding property etc.

For stuff like Javabeans, there's lombok, with the lombok maven plugin, delombok can be called on building, so there are no runtime dependencies.

[mishako]

The android not supporting jaxb is scary. Sounds like it's going to be a big and annoying problem.

[imk]

@mishako yeah, the goal "better android support" is making some things really hard :-)

[imk]

After looking at the discussions about code generation in the questionnaire, I would prefer to abstain from code generation. There is some strong resistance against code generation, so it would be an obstacle in getting developers involved.

But we could stil use some tools i.e. to generate initial classes from an xsd, but that code should be cleaned and checked in to source control instead of being generated at build time. Although I generally don't like putting generated code in source ccntrol ...

[mishako]

@imk I didn't see any good arguments against code generation in general. Lombok is special because it generates byte code, not source code. As you said in the other thread, Fedora packaging guidelines do allow use of code generators. I can see how lombok doesn't fit the definition of a code generator. I still don't understand how it is against the "No inclusion of pre-built binaries or libraries" though.

Anyway, I think as long as we stick to conventional code generators (e.g. autovalue) we're good.

[imk]

@mishako you're right, I haven't seen real technical or organizational arguments against code generation, just strong resistance by some developers. So it could be an obstacle in getting people involved. Personally, I still prefer not doing boring stuff tools can do for me. So I'm fine with any decision taken here, my view on pros and cons just slightly shifted because of the cons some others see and that I don't fully understand :) I'm curious about the opinion of the others more active here then me.

[mishako]

Okay, let's build the prototype with code generation, see how it works out and if people will like it. Closing the ticket.