Maven 1

Roadmap doc plugin

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Trivial Trivial
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: documentation
  • Labels:
    None
  • Number of attachments :
    4

Description

Hi,
would anyone be interested in a plugin which
generates a project roadmap?

This would be a simple report, linked from the
Project Documentation nav menu, and have sections
including:
. release version
. estimated release date
. line items including:
. functionality type (addition, change etc)
. description
. assigned developer

I would expect it to be very similar to the changes
plugin, and be generated by the inclusion of a roadmap.xml
file in the xdocs directory, e.g:

<document>
<body>
<release version="0.6" date="10-10-2003">
<action dev="tima" type="update">
Refactor administration UI.
</action>
...
</release>

<release version="0.7" date="Q1 2004">
....
</release>

<future>
<action dev="unassigned" type="add">
Add clustering support, based on javagroups.
</action>
</future>
</body>
</document>

Thoughts?

-Tim

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tim Anderson added a comment -

initial cut of the roadmap plugin.

Show
Tim Anderson added a comment - initial cut of the roadmap plugin.
Hide
Permalink
Emmanuel Venisse added a comment -

Can we add a status action (Done, In progress, To do, ...)?

Show
Emmanuel Venisse added a comment - Can we add a status action (Done, In progress, To do, ...)?
Hide
Permalink
Tim Anderson added a comment -

In the initial cut, there is a status column.
See http://openjms.sourceforge.net/roadmap-report.html for an example.

Show
Tim Anderson added a comment - In the initial cut, there is a status column. See http://openjms.sourceforge.net/roadmap-report.html for an example.
Hide
Permalink
Tim Anderson added a comment -

patch to xdoc plugin.jelly to include the report in the default reports, and exclude roadmap.xml from being transformed as a user doc

Show
Tim Anderson added a comment - patch to xdoc plugin.jelly to include the report in the default reports, and exclude roadmap.xml from being transformed as a user doc
Hide
Permalink
Brett Porter added a comment -

look great!

how about...
a) a legend for the types?
b) a release history for completed milestones (separate page or below the roadmap?) Just an identical transform, but based on a "completed" flag.
c) cvs tag and branch information (what it was tagged when it was released, what branch it is currently on if not HEAD, the last merge tag of that branch)

Show
Brett Porter added a comment - look great! how about... a) a legend for the types? b) a release history for completed milestones (separate page or below the roadmap?) Just an identical transform, but based on a "completed" flag. c) cvs tag and branch information (what it was tagged when it was released, what branch it is currently on if not HEAD, the last merge tag of that branch)
Hide
Permalink
Brett Porter added a comment -

sorry, I noticed in the issue you already have (b) - just didn't see it on the example page at openJMS

Show
Brett Porter added a comment - sorry, I noticed in the issue you already have (b) - just didn't see it on the example page at openJMS
Hide
Permalink
Tim Anderson added a comment -

> how about...
> a) a legend for the types?
Could do. This plugin is basically pinched from the changes report and given the similar content, should have the same L&F.

I actually like the way jira does it tho - as an annotation on the type image. I also like jira's images too, although I suspect atlassian would object if I copied them

> c) cvs tag and branch information (what it was tagged
> when it was released, what branch it is currently
> on if not HEAD, the last merge tag of that branch)

I view the roadmap plugin as being a record of future releases. Past releases would be the domain of the changes report.

Show
Tim Anderson added a comment - > how about... > a) a legend for the types? Could do. This plugin is basically pinched from the changes report and given the similar content, should have the same L&F. I actually like the way jira does it tho - as an annotation on the type image. I also like jira's images too, although I suspect atlassian would object if I copied them > c) cvs tag and branch information (what it was tagged > when it was released, what branch it is currently > on if not HEAD, the last merge tag of that branch) I view the roadmap plugin as being a record of future releases. Past releases would be the domain of the changes report.
Hide
Permalink
Brett Porter added a comment -

I guess my comments apply to the changes report more than this then.

But I wonder whether it would be better to integrate the two? Otherwise you would probably find you'd just be cutting and pasting to changes through from roadmap once a release is made. Better just to have a flag and generate two different files isn't it? I think that is possible with the reports, but I'm not quite sure...

Either that, or the two reports use the same source file, transforming different sections of it.

Show
Brett Porter added a comment - I guess my comments apply to the changes report more than this then. But I wonder whether it would be better to integrate the two? Otherwise you would probably find you'd just be cutting and pasting to changes through from roadmap once a release is made. Better just to have a flag and generate two different files isn't it? I think that is possible with the reports, but I'm not quite sure... Either that, or the two reports use the same source file, transforming different sections of it.
Hide
Permalink
Tim Anderson added a comment -

Yes and no. Having both changes and roadmap in the one report means you lose the ability to add xdoc <section> elements which only apply to one.

And some cutting and pasting would be required anyway, in order to convert a roadmap element to a change element.

Show
Tim Anderson added a comment - Yes and no. Having both changes and roadmap in the one report means you lose the ability to add xdoc <section> elements which only apply to one. And some cutting and pasting would be required anyway, in order to convert a roadmap element to a change element.
Hide
Permalink
Brett Porter added a comment -

I'm not sure what you mean about the xdoc section - why does it apply to only one? Are you referring to having one source file and two outputs or one source and one output?

As for the changing from roadmap to changes - I'm not sure why can't they be the same format? There is the same basic set of elements, a flag to say if it is future or past (or perhaps a different tag like your original schema), then other information that might be different, but just becomes an optional element in the XML (or in your original schema, can be a different sequence I guess).

What do you think? Maybe we could list out all the appropriate information for both reports and put together one source file format. I like the idea of producing two documents though.

Show
Brett Porter added a comment - I'm not sure what you mean about the xdoc section - why does it apply to only one? Are you referring to having one source file and two outputs or one source and one output? As for the changing from roadmap to changes - I'm not sure why can't they be the same format? There is the same basic set of elements, a flag to say if it is future or past (or perhaps a different tag like your original schema), then other information that might be different, but just becomes an optional element in the XML (or in your original schema, can be a different sequence I guess). What do you think? Maybe we could list out all the appropriate information for both reports and put together one source file format. I like the idea of producing two documents though.
Hide
Permalink
Tim Anderson added a comment -

Theoretically (meaning I haven't tried it, you can mix any xdoc element in the changes/roadmap reports, e.g:

<body>
<section name="Roadmap">
This document provides a tentative roadmap for
OpenJMS
</section>
...
<release version="...">
</release>
</body>

...supporting the above means that the changes/roadmap can't be in the same document, unless new tags are introduced e.g:
<body>
<roadmap>
<description>This document ...</description>
<release version="..."/>
</roadmap>
<changes>
<description>Release notes for OpenJMS</description>
<release version="..."/>
</changes>
</body>

Doesn't seem to be a lot of point to me. I think it would be easier to have 2 source documents.

I don't have any problem with the same plugin generating both reports - seems like a sensible approach.
I've started to modify the changes plugin along these lines, but I'm running into problems with jelly. Any objections to a rewrite in XSLT (which works)?

Show
Tim Anderson added a comment - Theoretically (meaning I haven't tried it, you can mix any xdoc element in the changes/roadmap reports, e.g: <body> <section name="Roadmap"> This document provides a tentative roadmap for OpenJMS </section> ... <release version="..."> </release> </body> ...supporting the above means that the changes/roadmap can't be in the same document, unless new tags are introduced e.g: <body> <roadmap> <description>This document ...</description> <release version="..."/> </roadmap> <changes> <description>Release notes for OpenJMS</description> <release version="..."/> </changes> </body> Doesn't seem to be a lot of point to me. I think it would be easier to have 2 source documents. I don't have any problem with the same plugin generating both reports - seems like a sensible approach. I've started to modify the changes plugin along these lines, but I'm running into problems with jelly. Any objections to a rewrite in XSLT (which works)?
Hide
Permalink
Tim Anderson added a comment -

Rolls the roadmap plugin into the changes plugin. This replaces the previous patches.

Show
Tim Anderson added a comment - Rolls the roadmap plugin into the changes plugin. This replaces the previous patches.
Hide
Permalink
dion gillard added a comment -

Does the patch apply? And has it been tested?

Show
dion gillard added a comment - Does the patch apply? And has it been tested?
Hide
Permalink
dion gillard added a comment -

Patch for project.xml to include xalan

Show
dion gillard added a comment - Patch for project.xml to include xalan
Hide
Permalink
dion gillard added a comment -

Details from Tim:
The changes.zip file attached to the bugrep is the relevant patch.
It updates:
src/plugins-build/changes/plugin.properties
src/plugins-build/changes/plugin.jelly
src/plugins-build/xdoc/plugin.jelly
and adds:
src/plugins-build/changes/src/plugin-resources/changes.xsl

The changes.xsl replaces changes.jsl.

The only other change that needs to be made is to project.xml,
to add xalan (see attached). Forgot to add this as in beta 9 as I'd hacked
forehead.conf to workaround classloader problems. Beta 10 seems to
have resolved this.

The openjms website has both reports:

http://openjms.sourceforge.net/changes-report.html
http://openjms.sourceforge.net/roadmap-report.html

The changes report was generated to not include the dev column:

  1. Disable developer column in changes report
    maven.changes.include.dev=false
    Regards,

Tim

Show
dion gillard added a comment - Details from Tim: The changes.zip file attached to the bugrep is the relevant patch. It updates: src/plugins-build/changes/plugin.properties src/plugins-build/changes/plugin.jelly src/plugins-build/xdoc/plugin.jelly and adds: src/plugins-build/changes/src/plugin-resources/changes.xsl The changes.xsl replaces changes.jsl. The only other change that needs to be made is to project.xml, to add xalan (see attached). Forgot to add this as in beta 9 as I'd hacked forehead.conf to workaround classloader problems. Beta 10 seems to have resolved this. The openjms website has both reports: http://openjms.sourceforge.net/changes-report.html http://openjms.sourceforge.net/roadmap-report.html The changes report was generated to not include the dev column:
  1. Disable developer column in changes report maven.changes.include.dev=false Regards,
Tim
Hide
Permalink
Tim Anderson added a comment -

This issue can be closed. The patch is out of date with respect to the changes plugin in RC1.

Show
Tim Anderson added a comment - This issue can be closed. The patch is out of date with respect to the changes plugin in RC1.
Hide
Permalink
Brett Porter added a comment -

reporter asked for it to be closed.

Show
Brett Porter added a comment - reporter asked for it to be closed.
Hide
Permalink
Rodrigo Vega added a comment -

Sorry to comment in a very old thread, but i'm looking for a plugin to do exactly this. There is some one? I take a look to changes plugin but it doesn't have anymore the roadmap functionality in M2.

Can somebody point me to the right place?

Show
Rodrigo Vega added a comment - Sorry to comment in a very old thread, but i'm looking for a plugin to do exactly this. There is some one? I take a look to changes plugin but it doesn't have anymore the roadmap functionality in M2. Can somebody point me to the right place?

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.