Essentials Overview Features License Installation FAQ Sample Sites Resources Todo Changes Download Binaries Source Code Supporting Projects Documentation Configuration Guide Javadocs Development Jetspeed Tutorial Portlet Catalog Components Registry Security Syndication WAP Customization Cache PSML Forwards Get Involved Contributors CVS Repository View CVS CVS Branches Coding Spec Bug Database |
Overview
Coding Standards
See http://jakarta.apache.org/jetspeed/site/code-standards.html
Using an IDE
See http://jakarta.apache.org/site/idedevelopers.html
Castor Generated XML APIs
Instead of using SAX directly, Jetspeed uses Castor to parse out our XML. This has the benefit of not having to updated Java source code evertime we change our XML specification. This isn't a perfect situation. The Castor generated code is not standardized and allows developers to have access to information that isn't necessary (IE APIs for serializing an object to XML). As of Jetspeed 1.2, all Castor APIs are in dedicated packages off of org.apache.jetspeed.xml.api. This code should never be updated. There are two packages dedicated to having peer classes. org.apache.jetspeed.registry.peer and org.apache.jetspeed.psml.peer. Each of these packages was generated from XJay (http://xjay.sourceforge.net/) and are very simple Java classes (the prototypes for these objects are generated with XML Schema). Due to the fact that the jetspeed-config and psml XML Schemas share similar structure, some object within Jetspeed have duplicate name. Ex: org.apache.jetspeed.registry.peer.PortletEntry and org.apache.jetspeed.psml.peer.PortletEntry. It is crucial that you don't accidentally import from both packages at the same time. This is a necessary evil due to the fact that each object/xml element shares a similar structure. It is important to note that each is necessary to constrain the data. If anyone has an alternative recommendation on how to avoid this duplication a PROPOSAL would be welcome.
Copyright © 1999-2002, Apache Software Foundation