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]
