Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/Documentation/Requirements"

m (C1. Open)
m (C2. Simplify)
Line 64: Line 64:
 
* Single repository where all content is managed and authors simply add and enhance without duplication of effort
 
* Single repository where all content is managed and authors simply add and enhance without duplication of effort
 
* Content is tagged with the versions it is relevant to. This enables new content to be added for older functionality and have it picked up in all applicable versions of ELUG when next generated.
 
* Content is tagged with the versions it is relevant to. This enables new content to be added for older functionality and have it picked up in all applicable versions of ELUG when next generated.
 +
**Also allows end users to dynamically query the repository and build "custom" deliverables on-the-fly
 +
* Content is stored by '''topic''' (i.e., information-centric) rather than by page or chapter (i.e., book-centric)

Revision as of 09:31, 30 November 2009

EclipseLink Documentation Requirements

This page captures the requirements for future versions of the EclipseLink User Guide (ELUG). This is a work in progress.

Users

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
  • DBWS

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

U3. Consumable

It would be nice to enable the version specific ELUG content to be consumable into other documentation sets. Products and other projects that include EclipseLink should be able to consume the specific version of the ELUG matching the version they include.

Example: Oracle TopLink, Oracle WebLogic, GlassFish, and SAP NetWeaver do or will ship EclipseLink. Ideally these projects/products want to embed the version specific ELUG into their overall documentation set so that their end users have a consistent experience using their documentation.

Should:

  • Support producing an HTML and/or PDF documentation output for a specific version that consumers can use
  • License the content under a license that enable consumers to include--the Eclipse Foundation has endorsed a Creative Commons license for non-code artifacts--need to use approved license.

Nice to Have:

  • Enable consumers to skin the documentation for their own Look & Feel
  • Enable consumers to include and cross-link into the content from their own content that wraps the ELUG
  • Enable packaging as Eclipse IDE on-line help for inclusion with distributions that include EclipseLink components.

Contributors

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.

C1. Open

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
  • Content stored in an "open" format (i.e., XML)
  • Content format conforms to an established standard (DITA or Docbook?)
  • 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
    • Alternative is to allow project committers to provide doc updates directly to the the repository, similar to how we currently allow any committer to update the end-user wiki content.

C2. Simplify

The content authors need to be able to manage the content in an efficient manor.

Nice To Have:

  • Single repository where all content is managed and authors simply add and enhance without duplication of effort
  • Content is tagged with the versions it is relevant to. This enables new content to be added for older functionality and have it picked up in all applicable versions of ELUG when next generated.
    • Also allows end users to dynamically query the repository and build "custom" deliverables on-the-fly
  • Content is stored by topic (i.e., information-centric) rather than by page or chapter (i.e., book-centric)

Back to the top