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]
