gurkerl83 commented on pull request #101: URL: https://github.com/apache/jclouds/pull/101#issuecomment-803575347
I am open to using source code quality assurance tools; however, I have a few requirements for integrating and configured them into a project. The following points relate to the Maven configuration of the project module; this is already very extensive in terms of Maven plugins used and corresponding configuration detail. Note: I know Maven well enough to say that a great detail of configuration prevents the understanding of essential steps involved in a build process; beginners cannot differentiate crucial from optional build steps. An excess of configuration in the individual build steps also makes it difficult to adapt configurations once they have been integrated, or to remove them completely, because a problem that was fundamental at time A has been solved at time B by general adaptations or developments, for example in the programming language or the development tools. When I made superficial rebuilds to the Maven build a few weeks ago, I also researched the error-prone configuration. This has been in the POM file for a long time and was copy-and-pasted from the Error-Prone project page. This is precisely the kind of situation to avoid; when developers leave the project, the expertise gets lost, and complex configuration fragments remain in a project for a long time. Although many of the rules included by the Error-Prone plugin are also supported by development tools such as IntelliJ, there is still a permission base to use the plugin. To further minimize the project module's configuration, I tend to put the configuration of the plugin or the configuration of the Maven compiler plugin into a settings.xml and call Maven accordingly. The configuration of the compiler options could be passed as a property to the Maven compiler plugin. To support different JDKs, perhaps create additional settings.xml files. Due to more JDK variants' support, the profiles will grow; a separation at this level dedicated settings.xml files tailored to one platform would prevent a configuration mess. In any case, efforts to improve the build setup should be geared towards reducing the build configuration's size. Thx! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
