EclipseLink Documentation Requirements
This page captures the requirements for future versions of the EclipseLink User Guide (ELUG). This is a work in progress.
These requirements are for the consumers of the EclipseLink documentation which includes both the community using EclipseLink from eclipse.org as well as companies who redistribute EclipseLink and want to include or link to the ELUG.
U1. Version Specific
Each release and patch-set of EclipseLink should be able to offer ELUG content that is version specific.
- Provide links to ELUG for a specific version that navigates only to pages with content for this version
- Each release notes page (wiki) will link to the main
U2. Technology Specific Documents/Books
The documentation must be organized into technology (persistence service) specific document sets/books.
- JPA: Content focused on using EclipseLink JPA along with its advanced features
- Native API usage shown only in the
- MOXy: Content focused on EclipseLink MOXy usage including JAXB annotations, native eclipselink-oxm.xml and native API configuration and usage
- SDO: Content focused on EclipseLink SDO
- May make sense to combine with MOXy
- DAS (SDO-JPA bridge using MOXy) should be covered and can link to JPA content as necessary
Common Requiresments for all sets/books:
- The content of each set/book can share content but should be presented in the context of the technology being covered and avoid generic content containing links to its use in a variety of technologies - we should discuss this one
This section captures the requirements of the content producers. The goal is to streamline content development addressing the complex nature of the software spanning multiple technologies with shared infrastructure and thus common functionality.
The content must be developed in an open fashion so that any interested party can participate in the development and ongoing maintenance of the ELUG.
- Content must be developed in a repository that is generally accessible over the internet
- Approved content developers from any organization must be able to have write access to the repository. Generally this involves contributors providing documentation fixes and enhancements through bugs and the document authors being project committers having write access to the content repository