Subject area OMRS - redundant generated file

[odpi]

Subject area OMRS - redundant generated file

[planetf1]

There's a futher issue I found that generated sources are being left behind even after a 'clean' making it dubious to validate the effect of a clean build. The code generator places code into the source build tree -- ideally it should go under 'target'. Additionally it is the subject-area-tools module that creates the files, but places them into another modules' directory (subject-area-server), during the standard compile phase - going this doing 'generated-sources' would be more standard. I think we're breaking lifecycle and module isolation best practice?

For now I've added a maven-clean-plugin useage within the tools pom, this is at least aligned with the maven-exec which calls the generator. I initially tried adding to subject-area-server, but due to the above it gets executed at the wrong time.

Tested
mvn clean - no generated sources
mvn clean install - works ok builds, UT runs
mvn clean install - as above
mvn clean - to check clearout
mvn clean install - still builds

The only breakage could be in building individual modules where there is a dependency, but this is no different to the original poms.

[planetf1]

Managed to reproduce an issue reported by @mandy-chessell and @cmirash

[WARNING]
java.io.FileNotFoundException: open-metadata-implementation/access-services/subject-area/subject-area-server/src/test/java/org/odpi/openmetadata/accessservices/subjectarea/generated/server/TestSubjectAreaBeansToAccessOMRS.java (No such file or directory)
at java.io.FileOutputStream.open0 (Native Method)

It turns out there was a bug in the subject area generator, which means it was not generating the output folder correctly for the test java class.

When my original fix removed the redundant checked-in (to git) generated file, the generator then would only work if theoutput directory open-metadata-implementation/access-services/subject-area/subject-area-server/src/test/java/org/odpi/openmetadata/accessservices/subjectarea/generated/Test existed. This may or may not exist depending on prior git history - as git itself doesn't manage folders. So some environments might have had them, others not.

The generator code had logic to create the folder, but it only tried to create using 'mkdir()'. This was failing (but error code not checked) as the parent path didn't exist. I changed to using mkdirs() and the directory now seems to be consistently created.

On David's suggestion I also added cleanup of the test folder (in fact this exacerbated the above initially.. and led to me being able to reproduce)

This patch should be good ! :-)