Feature/add flag to ignore existing generated sources

[nkengasongatem]

Summary

Adds a new compileProject flag to prevent Java compiler Filer errors caused by already existing generated sources.

New property:

• ivy.compiler.failOnExistingGeneratedSources (default: true)

When set to false, compileProject prevents (for now, ignores) the specific InvocationTargetException case whose cause contains:
Problem with Filer: Source file already exists

Why

This supports annotation-processing setups where generated sources may already exist before compileProject runs, for example Hibernate JPA static metamodel generation.

Notes

• The option is already passed into the engine options map as ivy.compiler.failOnExistingGeneratedSources.
• The plugin currently contains a temporary fallback check in CompileProjectMojo.
• This fallback can be removed later once the engine honors the option directly.

Tests

Updated TestCompileProjectMojo to cover:

• detection of the specific Filer duplicate-source error
• ignore behavior when the flag is false
• non-ignore behavior when the flag is true
• no change for unrelated compile failures

Example

<failOnExistingGeneratedSources>false</failOnExistingGeneratedSources>

[nkengasongatem]

Hi @ivy-lgi could you have a look at this when you have time? thank you.

[ivy-rew]

Thanks for proposing this enhancement @nkengasongatem

I think we need to make sure, that no existing configuration option is there to prevent the error.
Also I want to make you aware that we have already switch to use the Maven default compiler on 14.0.0-SNAPSHOTS. Which will make this change obsolete. However, we may apply it for LTS12 as an intermediate solution.

Have you already explored, with:

• disabling all warnings: axonivy/demo-projects@2d2498c#diff-041d9277977eba84fdbc941f8f0105c020bd22ece560c832ed84e9b8aae92ec1L57 ... or is it actually an error?
• existing options of the JDT compiler to to change the severity of a problem. Have you tried these to the issue at hand?

https://axonivy.github.io/project-build-plugin/snapshot/12.0/compileProject-mojo.html#compileroptions

you can print the options:

 <compilerOptions> <arg>-help<arg> </compilerOptions>

output:

 Warning options:
    -deprecation     + deprecation outside deprecated code (equivalent to
                       -warn:+deprecation)
    -nowarn -warn:none disable all warnings
    -nowarn:[<directories separated by :>]
                       specify directories from which optional problems should
                       be ignored
    -?:warn -help:warn display advanced warning options
 
 Error options:
    -err:<warnings separated by ,>    convert exactly the listed warnings
                                      to be reported as errors
    -err:+<warnings separated by ,>   enable additional warnings to be
                                      reported as errors
    -err:-<warnings separated by ,>   disable specific warnings to be
                                      reported as errors
 
 Info options:
    -info:<warnings separated by ,>   convert exactly the listed warnings
                                      to be reported as infos
    -info:+<warnings separated by ,>  enable additional warnings to be
                                      reported as infos
    -info:-<warnings separated by ,>  disable specific warnings to be
                                      reported as infos

If you share a minimal project where this error occurs, we can assist you in pin pointing whether an existing configuration can handle the problem.

[nkengasongatem]

Thanks for the review and the pointer about v14.0 @ivy-rew , I was not aware of this so from my point of view it is okay that this proposal is only an intermediate solution for LTS12.

Regarding the current issue: in the reproducer (see link below) it is a compiler error, not a warning. The output is:

Java compiler error : 1. INFO: Hibernate JPA 2 Static-Metamodel Generator 5.6.15.Final
ERROR: Problem with Filer: Source file already exists : entities.Station_
2 problems (1 error, 0 warnings, 1 info)

Because of that, disabling warnings do not help. Here is a minimal reproducer:

https://github.com/nkengasongatem/db-test

The error can be reproduced with:
mvn test

I tried cleaning the src_generated at the "initialize" phase, but then I could no longer use the pro designer because any significant change during development would clean the sources and my project would break. For my pipeline, I currently just delete the sources in the test stage (that were created during the build stage) but the main pain point is during local development. Here I tend to run tests (and run other maven commands) quite often, and having to clean each time is not very convenient.

[ivy-rew]

Ok thanks for sharing the comprehensive miniaml example. I've shortly verified your setup.

• As you said, proper "clean" run would address the issue at hand. So I have to dismiss this PR. Everything works as designed.

Workaround:

• In your db.test you have configured the hibernate-modelgen plugin dependency, which will contribute to the compiler run ... and this annotation process fails if the clean lifecycle was not invoked.
• Therefore I'd simply isolate the hibernate-modelgen dependency in a profile. So that in your normal maven runs, the annotation processing is not active. Still you can actively enable it by opting-in, in case you want to re-generate meta models
  • normal runs: mvn test (no modelgen: expect classes to exist from previous runs)
  • re-generate runs: mvn clean test -P modelgen

  <profiles>
    <profile>
      <id>modelgen</id>
      <dependencies>
        <dependency>
          <groupId>org.hibernate</groupId>
          <artifactId>hibernate-jpamodelgen</artifactId>
          <version>5.6.15.Final</version>
          <scope>provided</scope>
        </dependency>
      </dependencies>
    </profile>
  </profiles>

Full example (your db.test/pom.xml with a profile):
pom.xml

Does that help you?

[nkengasongatem]

Thanks for the detailed feedback and the profile suggestion @ivy-rew. I agree the profile approach is valid, but I am not sure it is the most practical solution:

The issue isn't limited to mvn test — it affects the entire Maven lifecycle. mvn package, mvn install, mvn verify — all of these fail too, because the generated sources already exist. That means the profile approach isn't something developers opt into occasionally for regeneration: they'd have to always remember to append -P modelgen to every Maven command, or never use it and risk stale metamodels. Neither is a natural development flow from my point of view. And yes, aliases could help, but that just moves the cognitive load off the command line and onto onboarding docs, team conventions, and IDE configurations — it doesn't eliminate it.

In contrast, failOnExistingGeneratedSources=false in the pom.xml just works — for every lifecycle, for every developer, with zero extra steps or tribal knowledge. That's the ergonomic value I was going for.

Ideally this would be handled at the engine level via the options map (the option ivy.compiler.failOnExistingGeneratedSources is already being passed through) — that would make it a first-class, robust solution rather than a plugin-level exception catcher. But that is not something I can send in a PR myself.

The profile approach does work, but as outlined above it comes with a cognitive overhead. Either way, thank you for taking the time to review and for the detailed feedback, I really appreciate — feel free to close this PR if you don't see it fitting for LTS12 :)