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] > >
