-
Notifications
You must be signed in to change notification settings - Fork 0
Description
In order to ensure no null analysis warnings are generated during the Maven build, we must provide the external null annotations to the compiler. We did this in commit d3e0272. However, the implemented solution contains two problems:
- It will only work when running the build in a specific manner, which matches the manner in which the build runs on the CI server. From the repo root, building the entire
mainproject, as in:
$ mvn -f main/org.gamegineer.main/pom.xml clean install
should result in no null analysis violations. However, running the build locally from any subproject will produce null analysis warnings as the relative path to the external annotations is no longer correct. - Referring to files outside of the project is a Maven anti-pattern. The correct way to access the external annotations from any project is to publish them to a Maven repository and configure them as a dependency for all relevant projects. That dependency can then be unpacked locally and referred to in a project-agnostic manner.
Both problems can be addressed by publishing the contents of the org.gamegineer.other.settings project to the Maven repository and then referencing that project as a dependency of all the subprojects under the main project.
I see the other project becoming another top-level project, just like target-platform, third-party, etc. It should be built before main to ensure its modules are deployed to the repository before the main subprojects require them.
I don't foresee a problem with how we currently reference the org.gamegineer.other.settings project from within the Eclipse workspace (in order to access the external null annotations), but I haven't thought about it deeply. I believe Eclipse will continue to refer to the external null annotations via a (project-relative) file reference rather than through the target platform.