Musings
The following is a list of things that are being contemplated
for Maven.
-
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.
-
The integration of Quilt.
David Peugh's is working on this and Quilt is available
here.
-
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.
-
Find all unreferenced files in a project so that developers know
where the dead code is.
-
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.
-
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.
-
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.
-
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.
-
Integration with various issue tracking systems.
-
Integration with Eyebrowse.
-
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.
-
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.
-
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.
-
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.
-
Need to get at access to the distributions that are made and building
reports based on the information.
-
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).
-
A common format for project usecases. Scarab has made a start here so that
would be good to integrate.
-
A common format for a project roadmap. Take a look at some formats
provided by the Unified Software Development Process.
-
How to easily link to references. The same mechanism that is used to
link entries in the glossary can be used.
-
Automate the archiving of the mail to mail-archive.com or
at least provide instructions on what to do.
-
Standard JavaCC pattern. Maven, Lucene, Jython all need something
like this and now that JavaCC is OSS it will be even easier!