David wrote:
I'd like to call a vote for releasing the axistools 1.2 plugin.
+0, not using it.
There are issues left - and some cleaning up could still be a really
good idea,
Just to make sure, it's explicitly mentioned:
"mvn docck:check" reports quite a dozen of mojo parameters which have no
documentation.
Also, the POM is missing a <license> element (seems to be ASL 2.0).
"mvn dependency:analyze" shows some oddities with the Maven dependencies.
The site descriptor can be trimmed down, e.g. banners and links are
inherited.
The POM snippets on the plugin's usage/example pages don't include a
<version> element as suggested by best practices.
Furthermore, the POM snippet on the usage page does not even give a
<groupId> which won't work since the default value is
"org.apache.maven.plugins".
The mojo parameters
- project in AdminMojo
- project in Java2WSDLMojo
- project in WSDL2JavaMojo
- pluginArtifacts in WSDL2JavaMojo
should be marked as @readonly to prevent user confusion.
The mojo parameter
- timestampDirectory in WSDL2JavaMojo
defaults to "${basedir}/target" which is better described by
"${project.build.directory}".
Likewise, the mojo parameter
- classesDirectory in Java2WSDLMojo
defaults to "${project.build.directory}/classes" which matches
"${project.build.outputDirectory}".
The method getRuntimeClasspath() in Java2WSDLMojo looks strange. First,
it neglects class path ordering as specified in the POM by storing the
paths in a HashSet. Second, the method queries
getRuntimeClasspathElements() although the mojo is only annotated with
"@requiresDependencyResolution compile", i.e. the plugin will usually
not see anything beyond compile scope.
The mojo parameter
- staleMillis in WSDL2JavaMojo
is never read (c.f. PMD report). Looks like a missing call to
WSDL2JavaPlugin.setStaleMillis().
Benjamin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
