Locally I can build core Egeria and get a valid generated file TestBeansToAccessOMRS.java.
I can confirm that the IJ build creates an invalid version of TestBeansToAccessOMRS.java with duplicate declarations.

I

• cloned the egeria repo (with up to date main) - so completely clean
• did a 'mvn clean install' at CLI
• Opened the directory with intellij 2022.3.1 ie as a new project
• Answered 'maven' when prompted for maven+gradle
• Let IntelliJ index etc
• Clicked 'build project'
• Clicked ' enable annotation processing' when prompted

The resultant build was clean

I inspected the file, and at line 126766 of TestBeansToAccessOMRS.java I see

MapPropertyValue testMapPropertyValue = null;

which reports no errors - but also different content on the line to the error you are reporting.

I do have many declarations of primitivePropertyValueForMap in the file, and also in this method testCreateAgreementItem() it is declared 4 times

             PrimitivePropertyValue primitivePropertyValueForMap = new PrimitivePropertyValue();

But the end result is

26/01/2023, 12:20 - Build completed successfully with 645 warnings in 30 sec, 306 ms

I had left my JVM at default. On checking, I am using 'temurin 17' - and the language level defaulted to 17 (this is something I usually check/change after importing a project
I also checked in settings under Maven, and I am running the Bundled maven 3 (3.8.1)

The editor marks this file as 'you are editing a file which is ignored' - which is good, since intelliJ knows this file is generated

Additionally, there are no graphical overlays on main/java or main/test - ie IntelliJ is not seeing these as source modules (and so wouldn't try to compile, or report any issues), but arguably this is also true, since they are generated and just an intermediate step of the build process.

So it would seem there are maybe two issues

• why do we have different behaviour in the IDE with some people seeing these files as buildable (I think it's right they are ignored? Maybe?)
• why is the invalid file not used -- does this mean the code isn't even running? I would see the maven/gradle builds as definitive here?

@davidradl @MihaiIliescu is the sequence I followed exactly the same as you?

Under Help->Custom properties, I also set 'idea.max.intellisense.filesize=10000' which allowed IntelliJ to analyze even these large source files (mem/cpu usage higher) which clarifies these issues in the file

For the gradle build, no code has been added to build/execute these tests at all - I missed this when doing the port
In the case of maven whilst test code is built, there is no execution. Looking at maven.

I think I have found a bug in the generator - just testing.

@planetf1 do you want to test #7325 .

I'm looking at why the tests don't run in our build. I can't see anything changed in maven for years .
However with our upcoming move to gradle I'll focus my fix there. Just experimenting at the moment - WITHOUT your fix, as first I went to see a compile failure! Then I will try together with your fix.

@planetf1 I will not merge until you give me the nod. @MihaiIliescu you could try applying the pr locally and test it works if you like

I have fixed up gradle to actually build the tests.
Next I will incorporate the code fix, and verify the tests run.

yes, I'll test it now

Just finished testing #7325.

Pulled David's PR, ran mvn clean install, and then build from Intellij with no errors. Great work!

There's a new PR #7327 which incorporates David's fix, but also corrects the gradle build to actually run the tests!

It was ready to merge, but blocked by many code style warnings from codeQL. Awaiting a decision as to what to do with those before we merge.

with the pending change to v4 I suggest this waits until after that (Monday 6 Feb)

@mandy-chessell @dwolfson

Though not directly related, I am intrigued if #7425 would make any difference

This should be fixed now, though note issue #7536