Overture Codegen does not re-generate as expected

[lausdahl]

Description

The generator skips generation eventough the input files have changed.

I know I could use mvn clean package to fix this but it is not obvious since java is incremental and it re-compiles changes where the code generator just ignores it. The simplest fix could be to store a checksum of the files in a log next to the generator output and compare this to decide if it should skip generation. A smart implementation would probably combine this with some dependency information and then just re-generate what's needed.

As a minium print the skipped generation using warning in the log. I only get this mixed in with lots of downloads and other text:

Skipping Java code generation. Output folder '/Users/kgl/data/agco/agco/tools/harvi/cgmasteralgorithm/target/generated-sources/javacode' already exists.

Steps to Reproduce

1. generate code from a specification, mvn package
2. delete one of the generated files (just to make it obvious that is doesnt generate the file
3. change a vdm file
4. mvn package
5. assuming that the file deleted was required then you get a compile error

Expected behavior: [What you expect to happen]

I expect the generator to re-generate the delta since last generation

Actual behavior: [What actually happens]

it just skipped generation which a not so obvious message somewhere in the console log

Reproduces how often: [What percentage of the time does it reproduce?]

100%

Versions

2.5.5-SNAPSHOT
Java 8
Mac High Sierra

[peterwvj]

I see what you mean, but this is intentional. Currently, the code-generator skips the generation step if the target folder already exists. Therefore, one must always run clean to trigger re-generation of code. I agree that the proposed approach is a better solution.

[lausdahl]

But you have no way of knowing this. Everything compiles as expected except you have wrong generated code.

I would prefer always to generate the code unless you are 100% sure that you would have generated exactly the same code.

Requiring you to call clean is not very maven compliant. Also it prints the message in clean text and not through the maven mojo warning. The problem is that if you run a long build then there is not an easy way to detect this mismatch between code and model.

[peterwvj]

Fixed in #664