Remove all xsd versions from the reference manual samples in favor of
"versionless" XSDs. For example, spring-beans-3.0.xsd becomes
spring-beans.xsd
Issue: SPR-10010
Convert all docbook XML files to well-formed docbook 5 syntax:
- Include xsi:schemaLocation element for tools support
- Convert all id elements to xml:id
- Convert all ulink elements to link
- Simplify <lineannotation> mark-up
- Fix misplaced </section> tags
- Fix <interface> tags to <interfacename>
- Cleanup trailing whitespace and tabs
Issue: SPR-10032
Problems
- Eliminate — in favor of —
— was causing 'no such entity' errors during docbook
processing; — produces the equivalent output.
- Fix column issues in appendices
column counts were set to 3, when they are in fact 4. This passed
under DocBook 4 and Spring Build for unknown reasons, but caused a
hard stop under DocBook 5 and the docbook-reference-plugin.
- Add jdbc callout section in docbook 5-friendly style
use <co/> tags as advertised in DocBook documentation.
- Set correct widths for PDF ref doc images
images were rendering larger than the PDF page; just set all to
width=400 and everything looks good.
Polish
- Update reference doc copyright to 2012
- Remove "work-in-progress" language from ref docs
- Update maven URLs to repo.springsource.org
- Update javadoc urls from 3.0.x/javadoc-api => current/api
- Replace hardcoded "3.1" with ${version} in ref doc
This change eliminates the spring-framework-reference subproject, moving
these sources into the root project's own src directory.
This makes sense because the reference docs span all submodules, and
also because api Javadoc is created at the root project level as well.
This means that both api and reference documentation output will now
reside in the root project's 'build' directory. This is more consistent
and easy to discover.
Prior to change, there were 175 instances of <methodname/> elements
including parentheses (e.g.: <methodname>foo()</methodname>, and
36 instances without.
Now all 211 instances include parentheses for consistency.
<programlisting/> elements must contain no newlines at beginning or end.
The following is an example of what not to do:
<programlisting><![CDATA[
package com.foo.bar;
class XFoo implements Foo<X> {
}]]>
</programlisting>
This leaves newlines at the beginning and end of the programlisting
panel within the PDF. Instead, do it like this:
<programlisting><![CDATA[package com.foo.bar;
class XFoo implements Foo<X> {
}]]></programlisting>
- The sentence at the end of section 5.5.5 now refers to the
<mvc:annotation-driven conversion-service="..."/> example at the end
of section 5.6.
- The sentence at the end of section 5.5.5 refers to the
FormatterConversionServiceFactoryBean section that follows.
Phillip Webb
Sam Brannen
Chris Beams
Chin Huang
Rossen Stoyanchev
Costin Leau
Juergen Hoeller
Keith Donald
Arjen Poutsma
Thomas Risberg