Yet, consider the case; To make a modification to documentation for a previous version that was taged in the CVS, you would need to branch and commit you changes to the branch, this would mean that if you wanted to "publish" these changes using maven, you would need it to checkout the latest head of that branch (you could still use tags to mark where you want publishing to occur on that branch).

If you wanted your changes to be reflected in future versions, then you would need to merge those changes back to the trunk. If this is javadoc, then we are talking about merging source java files, and I would be concerned about making sure inappropriate changes occured. If its userguide, then were talking about xdocs and its not so big an issue.

All I'm really stating is that we would have to become more savy when it comes to branching and merging in the CVS. Something which I'm not particularly good at or overjoyed about doing.

-Mark

[EMAIL PROTECTED] wrote:

commons-collections uses Maven to generate several versions of their
javadocs using various CVS tags.  I think we should incorporate this
into our Maven build if we want several javadoc editions accessible at
the same time.

For the user guide, I think a similar approach that capitalizes on CVS
tags could be used to generate several editions of the guide.

In addition to the benefits Phil mentioned, having Maven generate all
the documentation allows for any documentation modification, in either
a past version or present version, to be uploaded to the website in a
very easy and timely manner.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to