Hi, I agree too. IMHO we don't have to block a release because they are checkstyle errors : releasing something must not be nightmare (we are here to help users and fix issues). Ok except for missing license headers in source files. We will find some exceptions which will prevent automatisation of a such process.
-- Olivier 2008/7/21 Arnaud HERITIER <[EMAIL PROTECTED]>: > Couldn't we setup a custom profile for QA checks (pmd, checkstyle, clirr > ...) that we activate in a separate project in the CI server ? > It's what I begin to do at work. The advantage is to keep the integration > build fast and we can have a look at the QA builds to improve them. > > Arnaud > > On Mon, Jul 21, 2008 at 4:23 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > >> >> On 19/07/2008, at 11:26 PM, Dennis Lundberg wrote: >> >> I went and harvested the mojo-dev list for release vote comments, most of >>> the from Benjamin. Some are specific to plugins, but many are general. >>> Here's the list: >>> >> >> Thanks Dennis! (and Benjamin :) >> >> >>> >>> >>> Inherit from the latest released parent to benefit from its improvements. >>> >> >> Sounds like a good enhancement to the release:prepare goal, or maybe an >> enforcer rule. The only thing to ensure is that it isn't applied when the >> build from the tag occurs later. >> >> >>> >>> If the latest parent-SNAPSHOT has important fixes, copy these to the >>> components POM. Add a comment that they can be removed when parent X is >>> released. >>> >> >> This seems like a bad workaround for not releasing a parent. Isn't a better >> rule to release the parent instead? Resolving snapshot dependencies of all >> kinds is just part of any release process. >> >> >>> >>> Run "mvn docck:check" to make sure the documentation is good. >>> >> >> This should be automatable since I Think they all pass already? >> >> Check that a plugin's index page follows the template from the plugin >>> documentation standard. >>> >> >> Is there anything we can do to automate that in docck, or does it need to >> be eyeballed? >> >> >>> >>> To promote the best practice of specifying versions, POM snippets in the >>> docs should have a <version> element. >>> >> >> Can that be added to the documentation guide? >> >> >>> >>> Check the Checkstyle/Clirr/CPD/PMD reports for any issues. >>> >> >> These can be automated on release once we get to a baseline where they >> pass? I don't think the burden should be on the next releaser to have to fix >> all this up - we don't want artificial roadblocks to releases. >> >> >>> >>> The POM must have an <scm> element, to make its "Source Repository" report >>> correct. >>> >> >> I think that's irrelevant for us since it's inherited correctly (and >> release fails without it). >> >> >>> >>> Use "mvn dependendcy:analyze" to find used but undeclared artifacts as >>> well as unused but declared artifacts. >>> >> >> I think this falls under a similar category to Clirr, etc. >> >> >>> >>> For mojo parameters, using the annotation "default-value" is recommended >>> over "expression" when accessing POM elements like build directories [0, 1] >>> and boolean values. >>> Using "default-value" will make the expression show up nicely on the >>> mojo's info page. If the parameter should be set-able from the command line >>> an "expression" is needed. >>> >>> [0] >>> http://www.nabble.com/Difference-between-default-value-and-expression-metatags-td5725581.html >>> [1] >>> http://www.nabble.com/Plugin-Parameters%3A-expression-vs.-default-value-td15109298.html >>> >>> Investigate if a plugin suffers from any of the Common Bugs [2]. >>> >>> [2] >>> http://maven.apache.org/guides/plugin/guide-java-plugin-development.html >>> >>> If a component requires Java 1.5 to run, then this must be documented, >>> i.e. using the "target" option of the >>> compiler. For plugins this should be picked up by Maven Plugin Plugin 2.4 >>> when generating the plugin-info.html. For non-plugins this must be >>> documented manually. >>> >>> Updating the plugin to use the latest release of the Invoker Plugin (1.2) >>> could ease integration testing: >>> - convenient staging of plugin artifact into isolated local repo [3] >>> - separation of IT build output from version controlled directories [4] >>> - checking for failing IT builds [5] >>> >>> [3] >>> http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html >>> [4] >>> http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#cloneProjectsTo >>> [5] >>> http://maven.apache.org/plugins/maven-invoker-plugin/faq.html#question2 >>> >> >> These all get into development time questions rather than release time >> questions - worth considering PMD rules for all of the above which I think >> has been considered before. >> >> Cheers, >> Brett >> >> -- >> Brett Porter >> [EMAIL PROTECTED] >> http://blogs.exist.com/bporter/ >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
