jvanzyl 02/03/21 11:15:03
Modified: xdocs goals.xml musings.xml
Added: xdocs articles.xml distributions.xml glossary.xml
Log:
Adding more docs.
Revision Changes Path
1.3 +3 -1 jakarta-turbine-maven/xdocs/goals.xml
Index: goals.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-maven/xdocs/goals.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- goals.xml 24 Feb 2002 16:30:08 -0000 1.2
+++ goals.xml 21 Mar 2002 19:15:03 -0000 1.3
@@ -12,7 +12,9 @@
Maven's primary goal is to allow a developer to comprehend the
complete state of a development effort in the shortest period of time.
</p>
-
+ </section>
+
+ <section name="Visualization of Project Information"
<p>
In order to aid in that comprehension, it will be necessary not
only to produce metrics for the source base in question but to provide
1.15 +146 -107 jakarta-turbine-maven/xdocs/musings.xml
Index: musings.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-maven/xdocs/musings.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- musings.xml 21 Mar 2002 04:09:49 -0000 1.14
+++ musings.xml 21 Mar 2002 19:15:03 -0000 1.15
@@ -20,124 +20,163 @@
the development of ajc.
</li>
<li>
- possibly incorporate <a
href="http://www.cs.uoregon.edu/research/perpetual/dasada/Software/Gretel/";>Gretel</a>,
looks similar to quilt.
+ Repository log analyser. Right now we have Juan's RCS file parser so
+ what would be the best way to leverage that tool. It would be great
+ to have graphs of the the activity to see where the action is.
</li>
<li>
- how to easily extend the build system for project specifics, we don't
- want people editing the generated build system. has to be easy and clear.
- </li>
- <li>
- have to figure out the structure for a jar repository and the naming
- conventions.
- </li>
- <li>
- separate the test inputs from the test classes, makes the include/exclude
- patterns much easier to deal with
- </li>
- <li>
- encourage the use of a central repository of JARs -> ${lib.repo}
- </li>
- <li>
- object model for a java project
- </li>
- <li>
- the project is the unit of work for alexandria and that's
- the idea we want to stress.
- </li>
- <li>
- cvs log analyzer
- </li>
- <li>
- build tool
- </li>
- <li>
- updater
- </li>
- <li>
- cross referencer
- </li>
- <li>
- source formatter
- </li>
- <li>
- make something like webgain's Quality Analyzer
+ Integrate JRefactory to do some source formatting according to a
+ given style. It would be nice to integrate the way checkstyle,
+ JRefactory and other tools like that work from some sort of
+ source defintion. I believe the project object model can
+ store this information and we can make little adapters to
+ work with the various configuration file formats for the
+ various tools that are availble for use.
</li>
<li>
audit
</li>
<li>
- cover (david peugh's <a href="http://quilt.sf.net/";>Quilt</a>)
- </li>
- <li>
- metrics (easy enough with the java parser)
+ The integration of Quilt.
+ David Peugh's is working on this and Quilt is available
+ <a href="http://quilt.sourceforge.net/";>here</a>.
</li>
<li>
indexing tool for javadocs. search the repositories for code
that might be useful.
</li>
<li>
- graphs for cvs activity
- </li>
- <li>
- source metrics
- </li>
- <li>
- tool for taking patches
- </li>
- <li>
- updating tool
- </li>
- <li>
- installer help (webstart/jnlp)
- </li>
- <li>
- integrate ceki's dir layout
- </li>
- <li>
- integrate berin's build file
- </li>
- <li>
- standard location for libs versus distributions
- </li>
- <li>
- javadoc viewer
- </li>
- <li>
- make the tools easily integrated into cvs
- </li>
- <li>
- lxr finding all the source files that use a particular file,
- and finding unreferenced files in a code base.
- </li>
- </ul>
- </section>
- </body>
+ 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.
+ </li>
+ <li>
+ Find all unreferenced files in a project so that developers know
+ where the dead code is.
+ </li>
+ <li>
+ Have a set of indicators for cvs entries you don't want displayed in
+ the generated cvs log xdoc
+ </li>
+ <li>
+ 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.
+ </li>
+ <li>
+ Before warning users about jar that can't be distributed, check to make
+ sure they don't already have it. (warner's idea)
+ </li>
+ <li>
+ Figure the scenerio where the project must generate sources before
+ building. We have some crappy deps in the fulcrum build that need
+ to be cleaned up.
+ </li>
+ <li>
+ 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 scenerios plus if you have a testing machine for say
+ something like 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.
+ </li>
+ <li>
+ Must account for a difference between the login name on the machine
+ the user is working and where the site and distributions are
+ being deployed. Maybe some values in build.properties. Martin
+ can't currently deploy the site because of this.
+ </li>
+ <li>
+ integrate a simple link checker for the generated site so that
+ it is internally consistent.
+ </li>
+ <li>
+ 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 create 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. I
+ want to use Maven as a prototypical Turbine 3 application that
+ is controlled at the application model level and I'm 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 consise 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.
+ </li>
+ <li>
+ We need to make a glossary of terms for a project and we need a notation
+ that would us to link terms anywhere in the documentation to the
+ glossary of terms. We have something in the Tambora documentation that
+ uses javascript so we could probably steal that, or alternatively a
+ non-javascript solution. We just need accurate linking to terms. I
+ started a glossary for turbine3 so we can use that as a starter.
+ </li>
+ <li>
+ Integration with Scarab, how to make setting up Scarab easy for
+ users of Maven. We don't need a separate patch processing tool
+ now that we can use Scarab.
+ </li>
+ <li>
+ Integration with Eyebrowse.
+ </li>
+ <li>
+ Integration with these other tools obviously point to a plugin type
+ mechanism for adding different tools so I'm 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.
+ </li>
+ <li>
+ 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.
+ </li>
+ <li>
+ 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.
+ </li>
+ <li>
+ How to get subscribers to the various mailing lists. So we need some
+ sort of adapter to get at various systems like mailman or ezmlm.
+ </li>
+ <li>
+ Need to get at access to the distributions that are made and building
+ reports based on the information.
+ </li>
+ <li>
+ A Java graphing package so that we can implement some of Tufte's
+ ideas in graphical form. Is SVG a wise choice, does a browser need
+ a plugin or is there an easy way to convert images. JGraph will
+ produce SVG of a graph so we would need an easy way to convert
+ it to an easily viewable image.
+ </li>
+ <li>
+ Do we need to abstract out Ant so that projects can be built with
+ any tool.
+ </li>
+ <li>
+ Do we need to abstract out CVS so that any repository can work.
+ Probably because subversion is on its way and will more than
+ likely be ready soon and we want to take advantage of that.
+ </li>
+ <li>
+ How to integrate @todo items that are listed in the source with
+ todos that are unrelated to currently existing source files.
+ </li>
+ </ul>
+ </section>
+ </body>
</document>
-
-<!--
-. have a set of indicators for cvs entries you don't want displayed in
- the generated cvs log xdoc
-. when doing large builds consult .cvspass in order to find overriding
- values. at least make this the default.
-. Before warning users about jar that can't be distributed, check to make
- sure they don't already have it. (warner's idea)
-. Figure the scenario where the project must generate sources before
- building. We have some crappy deps in the fulcrum build that need
- to be cleaned up.
-
-Article references
-http://www.stqemagazine.com/featured.asp?id=20
-
-. 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.
-
-. must account for a difference between the login name on the machine
- the user is working and where the site and distributions are
- being deployed. Maybe some values in build.properties. Martin
- can't currently deploy the site because of this.
-
-. integrate a simple link checker for the generated site so that
- it is internally consistent.
-
--->
1.1 jakarta-turbine-maven/xdocs/articles.xml
Index: articles.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="[EMAIL PROTECTED]">Jason van Zyl</author>
<title>Articles</title>
</properties>
<body>
<section name="Articles">
<p>
http://www.stqemagazine.com/featured.asp?id=20
</p>
</section>
</body>
</document>
1.1 jakarta-turbine-maven/xdocs/distributions.xml
Index: distributions.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="[EMAIL PROTECTED]">Jason van Zyl</author>
<title>Distributions</title>
</properties>
<body>
<section name="Distributions">
<p>
</p>
</section>
</body>
</document>
1.1 jakarta-turbine-maven/xdocs/glossary.xml
Index: glossary.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="[EMAIL PROTECTED]">Jason van Zyl</author>
<title>Glossary</title>
</properties>
<body>
<section name="Glossary">
</section>
</body>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
