Musings

The following is a list of things that are being contemplated for Maven.

  1. Figure out how to specify that aspects are required. I would like to be able to make a huge reactor that the aspectj team can use to watch the development of the AspectJ compiler.
  2. The integration of Quilt. David Peugh's is working on this and Quilt is available here.
  3. Javadoc parsing has been added to the parser in Maven and it would be awesome to produce a javadoc indexing tool to help make it easy to search through a lot of Javadocs. David Flanagan has a tool called Jude which has been at version 0.9 for the last three years. It is very functional and uses an Antlr parser so maybe he would like to donate the code to Maven where it can be further developed.
  4. Find all unreferenced files in a project so that developers know where the dead code is.
  5. When doing large builds consult .cvspass in order to find overriding values. at least make this the default. We want it to be easy for people to use existing configurations where possible. In the same vein use the configuration mechanism for any of the SCM systems eventually.
  6. The use of profiles for testing like we have in the tdk and torque. How they can be made to work easily for developers working in different environments. We also want to be able use multiple profiles for testing so that a single developer can test several scenarios. Also, if you have a testing machine for, say, Turbine the profiles could get very sophisticated. You may want to test multiple servlet containers using multiple databases and you just want to cycle through the whole slew of profiles looking for problems.
  7. We need an easy way to access information from the project descriptor and we can't assume that the source of the information is an XML file. We should access the object model directly. We would like to be able to publish a site if the build is being controlled from a database. So we might want to revisit the the way the DVSL works and creates the documents from the object model and not the XML file directly. We started out with the storage of the model in XML form because it's easy but we don't want to box ourselves in. Maven will be used as a prototypical Turbine 3 application that is controlled at the application model level and we're going to use OJB to store the project object model in various places using the various persistence brokers available in OJB. One simple example is being able to reuse the description from the project descriptor in the documentation. The description, which would be available as $project.description in the velocity templates, could be the concise first paragraph that could be used as the opening paragraph on the index page and in any massive indices the description can be used and it will be consistent in many different locations.
  8. We need to make a glossary of terms for a project and we need a notation that would allow us to link terms anywhere in the documentation to the the definition of those terms in the glossary. We have something in the Tambora documentation that uses javascript so we could probably steal that, or alternatively a non-javascript solution can be employed. We just need accurate linking to terms. A glossary for terms has been started for turbine3 so we can use that as an example to start from.
  9. Integration with various issue tracking systems.
  10. Integration with Eyebrowse.
  11. Integration with these other tools obviously point to a plugin type mechanism for adding different tools so we're going to work on a small API based on the project object model so that tools can be easily added to plug in new tools.
  12. Distributing a dependency graph resource that will allow a project to state its direct dependencies and allow the consulation of the stored dependency graph to find the indirect (run-time) dependencies because you cannot force a project to keep track of another project's dependencies because it's just not manageable.
  13. Look at the Novosoft UML tools to see if we can automatically generate UML diagrams from the source. ArgoUML, I believe, is using Novosoft tools to reverse engineer a project to produce UML diagrams.
  14. How to get the number of subscribers to the various mailing lists. So we need some sort of adapter to get at various systems like mailman or ezmlm.
  15. Need to get at access to the distributions that are made and building reports based on the information.
  16. A Java graphing package so that we can implement some of Tufte's ideas in graphical representation of large data sets. JGraph will produce SVG. SVG can be viewed directly in many browsers (either with a plugin, or built in with recent versions of IE and Mozilla). Batik can be used to rasterize SVG for other targets (GIF and PNG for other browsers, PDF for printed materials).
  17. A common format for project usecases. Scarab has made a start here so that would be good to integrate.
  18. A common format for a project roadmap. Take a look at some formats provided by the Unified Software Development Process.
  19. How to easily link to references. The same mechanism that is used to link entries in the glossary can be used.
  20. Automate the archiving of the mail to mail-archive.com or at least provide instructions on what to do.
  21. Standard JavaCC pattern. Maven, Lucene, Jython all need something like this and now that JavaCC is OSS it will be even easier!