This is great as long as it does not become bureaucratic and onerous
for everyone to do a release.
How to prevent that is codify the process in the tooling. No one has
ever, and never will, follow a workflow that is defined in a document.
People are just people and most people themselves won't do it the same
way twice unless they do it often, and different people doing it the
same? No chance.
So if all this stuff was in a "pre-release-check" profile or something
that was consistently applied and showed people how to fix things that
would be awesome. Getting rid of all the crap that's collected in the
wiki would be great.
If you walked through all that stuff and created an actionable list to
correct that's great. If I have to run 10 commands, that everyone else
has to run people are just going to find variances and we're going to
have releases taking a week to fiddle around with the bits.
A first test of this toolchain could do an audit of all our plugins
and tell us how good (or bad) all the plugins are.
On 19-Jul-08, at 9:26 AM, 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:
Inherit from the latest released parent to benefit from its
improvements.
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.
Run "mvn docck:check" to make sure the documentation is good.
Check that a plugin's index page follows the template from the
plugin documentation standard.
To promote the best practice of specifying versions, POM snippets in
the docs should have a <version> element.
Check the Checkstyle/Clirr/CPD/PMD reports for any issues.
The POM must have an <scm> element, to make its "Source Repository"
report correct.
Use "mvn dependendcy:analyze" to find used but undeclared artifacts
as well as unused but declared artifacts.
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
Vincent Siveton wrote:
Hi guys,
What are the minimalist things that we need to check for a good
Maven release?
Dennis points that we need to reduce Checkstyle errors, checking
Clirr
report and licenses.
Any others ideas?
Cheers,
Vincent
---------- Forwarded message ----------
From: Dennis Lundberg <[EMAIL PROTECTED]>
Date: 16 juil. 2008 15:48
Subject: Re: [VOTE] Release Maven antrun plugin version 1.2
To: Maven Developers List <dev@maven.apache.org>
Thanks for pushing for this release Carlos!
Unfortunately there are a couple of things that needs to be fixed
before we can release 1.2, for which I have to vote -1 to the current
release candidate.
- The POM is missing the license header (I fixed this in svn)
- The Source files have the old license headers (I fixed this in svn)
- The documentation fix for MANTRUN-75 is not included in the 1.2 tag
Here are some minor things that are nice to fix prior to the release,
all of which I have fixed in svn trunk.
- Use latest version of maven-plugin-plugin and maven-site-plugin
- Fix errors reported by Checkstyle
- Add missing scm info in the POM
The Clirr report [1] shows one error, one of the constructors for
AntPropertyHelper has changed the number of parameters. This was done
in r374150 as part of the fix for MANTRUN-41. I guess that we can
live
with that change. Do we need to document it?
[1] http://maven.apache.org/plugins/maven-antrun-plugin-1.2/clirr-report.html
Carlos Sanchez wrote:
Hi,
9 issues fixed. Last release was 2.5 years ago
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125&styleName=Html&version=12210
Staging repo:
http://people.apache.org/~carlos/staging-repo
Staging site:
http://maven.apache.org/plugins/maven-antrun-plugin-1.2/
Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html
Vote open for 72 hours.
[ ] +1
[ ] +0
[ ] -1
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
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]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
