Tasks

Beta 5

  • Clear up remaining critical issues.

Unassigned

  • Generate xdoc from LICENSE.txt to show the project license and then link to it from the project info menu. Suggestion by Markus May that sounds good.
  • Roadmap document. (jvz)
  • Formalize how jarResources elements are moved from the project directory layout into the classpath for testing and into the JAR that is packaged with the distribution.
  • Write proposal for globally distributed JAR repository and distribution repository. There are definite things to be learned from the Perl folks.(jvz)
  • Need to restructure the mailing lists and object model so that we can easily select the dev mailing list for continuous integration problems. discovered when trying to apply the nag feature of gump.
  • Status document (weekly report type thing).
  • Look at release guide in tomcat 4.
  • Add maven:plugin-list target to list all known plugins from remote repos. Each repo may optionally provide a plugins.list file similar to the jars.list. A plugin is packaged as a jar file.
  • All plugins must provide intense sizzle, be goal-oriented, cooperate in a plug & play manner, and optionally provide a powerpoint presentation describing their management potential.
  • The inceptionYear and organization must be set in order for javadoc to work. i get illegal pattern char without, need to make sure those things are set.
  • How to generally deal with example code and where it belongs in the source tree and how it should be package in the distribution.
  • We need to detect whether we are running in a 1.4 environment and make the necessary adjustments if necessary. I believe there is currently a problem with XML parser classes being duplicated. (jvz)
  • Template for usecases.
  • Dealing with contrib and scratchpad areas.
  • How to shuffle your cvs structure around and keep your history. i notice some projects that I'm trying to mavenize have some pretty weird directory structures but it would be nice to be able to restructure the directory and still keep the history.
  • Release generated page based on the distribution directory and some standard text. just looking at things that can be culled from the turbine site.
  • Same with the 'how do i contribute' blurb at the bottom of the t2 pages. those can be generated.
  • JXR task needs to be modified so that XML is produced so that it can be transformed to into something that looks better.
  • A little report displaying the use of dev JARs as opposed to using released versions of products. Encourage projects to try and use released versions of JARs.
  • Need a way to transform a POM across multiple versions of Maven. For any number of reasons a project may decide to hold back on upgrading Maven immediately and we need to make sure that users can move safely upgrade across N versions.

Complete

  • Add support for the various coding specifications so that those properties can be applied to things like checkstyle and to create a document outlining the coding specification.
  • Maven:deploy-dist needs to work. (jvz)
  • Snapshot JARs need to be used for all versions of JARs that aren't released. So we can get rid of the update-jars functionalility.
  • Minimal reactor. This includes the dep graph, central repository of deps and all that jazz.
  • POM inheritence mechanism. Will wait for the switch to betwixt.
  • Generation of a standard build.xml file.
  • Script execution. Remove the requirement of the Ant execution environment. Along with this we'll get the exception handling we've been looking for.
  • See if jxr can be configured to only generate one file.gif and folder.gif, rather than one per source folder (dIon)
  • xref produces cross references for <sourceDirectories> and <testSourceDirectories>. javadoc produces html for <sourceDirectories> only.
  • When we are dealing with non-distributable JARs we may have to give the user some additional info like telling them they have to rename a JAR. So add another field which would contain a message blurb to display to the user in these cases.
  • A process for moving things from the task list to a list of items completed so they can be listed in documentation for a release automatically.
  • Schema for project.xml (jvz)
  • Maven POM updater: a reliable way to transform the project.xml file when changes are made. The coming changes to specification of tests will change the structure of the project.xml file and it should be easy for users to absorb these changes. They need to be notified, allowed to choose the changes when they wish and have the changes transparently applied.
  • Make a document that displays the list of currently registered projects.
  • Add a maven:xml-validate target which will validate all xml source against it's DTD (if present). Will most likely need a new element in project.xml (<xmlSourceDirectories>) similar to source directories. Any directory listed in an <xmlSourceDirectory> will be validated.