You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2004/04/12 18:39:30 UTC
svn commit: rev 9972 - in incubator/directory/rms/trunk: . api api/xdocs gui gui/main/xdocs gui/xdocs jdbc jdbc/xdocs jdbm jdbm/xdocs je je/xdocs jndi jndi/xdocs spi spi/xdocs xdocs
Author: akarasulu
Date: Mon Apr 12 09:39:28 2004
New Revision: 9972
Modified:
incubator/directory/rms/trunk/api/maven.xml
incubator/directory/rms/trunk/api/xdocs/navigation.xml
incubator/directory/rms/trunk/gui/main/xdocs/index.xml
incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml
incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml
incubator/directory/rms/trunk/gui/main/xdocs/rt.xml
incubator/directory/rms/trunk/gui/maven.xml
incubator/directory/rms/trunk/gui/xdocs/index.xml
incubator/directory/rms/trunk/gui/xdocs/navigation.xml
incubator/directory/rms/trunk/gui/xdocs/ocmm.xml
incubator/directory/rms/trunk/gui/xdocs/user-guide.xml
incubator/directory/rms/trunk/jdbc/maven.xml
incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml
incubator/directory/rms/trunk/jdbm/maven.xml
incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml
incubator/directory/rms/trunk/je/maven.xml
incubator/directory/rms/trunk/je/xdocs/index.xml
incubator/directory/rms/trunk/je/xdocs/navigation.xml
incubator/directory/rms/trunk/jndi/maven.xml
incubator/directory/rms/trunk/jndi/xdocs/navigation.xml
incubator/directory/rms/trunk/project.xml
incubator/directory/rms/trunk/spi/maven.xml
incubator/directory/rms/trunk/spi/xdocs/navigation.xml
incubator/directory/rms/trunk/xdocs/navigation.xml
Log:
o made some site documentation fixes
o switched to referencing the correct RMS jira
o corrected some build issues
Modified: incubator/directory/rms/trunk/api/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/api/maven.xml (original)
+++ incubator/directory/rms/trunk/api/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/api">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/api">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/api/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/api/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/api/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/gui/main/xdocs/index.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/index.xml (original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/index.xml Mon Apr 12 09:39:28 2004
@@ -1,21 +1,21 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <body>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>RMS Management Console (RMC)</title>
- </properties>
-
- <section name="RMS Management Console">
- <p>
- Welcome to the RMS Management Console Home Page!
- </p>
- <p>
- The RMS Management Console or RMC is used to manage the entities within
- a realm. Applications, users, profiles, permissions, roles et. cetera.
- are managed by environment operators using this console application
- which directly alters the authoritative RMS datastore.
- </p>
- </section>
- </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <body>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>RMS Management Console (RMC)</title>
+ </properties>
+
+ <section name="RMS Management Console">
+ <p>
+ Welcome to the RMS Management Console Home Page!
+ </p>
+ <p>
+ The RMS Management Console or RMC is used to manage the entities within
+ a realm. Applications, users, profiles, permissions, roles et. cetera.
+ are managed by environment operators using this console application
+ which directly alters the authoritative RMS datastore.
+ </p>
+ </section>
+ </body>
</document>
Modified: incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -1,15 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project>
- <title>RMS Management Console (RMC)</title>
- <body>
- <links>
- <item name="RMS" href="http://openrms.sourceforge.net"/>
- <item name="RMS" href="http://openrms.sourceforge.net"/>
- </links>
-
- <menu name="About RMC">
- <item name="Requirements" href="requirements.html"/>
- <item name="Random Thoughts" href="requirements.html"/>
- </menu>
- </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<project>
+ <title>RMS Management Console (RMC)</title>
+ <body>
+ <links>
+ <item name="RMS" href="http://openrms.sourceforge.net"/>
+ <item name="RMS" href="http://openrms.sourceforge.net"/>
+ </links>
+
+ <menu name="About RMC">
+ <item name="Requirements" href="requirements.html"/>
+ <item name="Random Thoughts" href="requirements.html"/>
+ </menu>
+ </body>
</project>
Modified: incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml (original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml Mon Apr 12 09:39:28 2004
@@ -1,209 +1,209 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <body>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>Rms Management Console Requirements</title>
- </properties>
-
- <section name="Rms Management Console Requirements">
- <subsection name="UI Description">
- <p>
- The UI will be designed to resemble the Microsoft Management Console
- (MMC) application. Snap-ins for the Rms console like MMC snap-ins
- will have other snap-ins associated with them heirarchically. The
- snap-ins and their heirarchy will be displayed like the MMC in a tree
- on the left hand side of a split pane.
- </p>
-
- <p>
- On the right hand side of the split pane plugins can display within a
- table any information they would like. Basically selecting a plugin
- node in the tree hands over control of this area to the right to that
- plugin. The plugin may populate the table with what ever content it
- needs as well as change the popup menus triggered on the cells of the
- table.
- </p>
-
- <p>
- On the tree display when expanding a plugin it is upto the plugin to
- return the set of child plugins to display. Each subordinate plugin
- when selected displays rows in the table to the right of the split
- pan in accordance with the context of the plugin. Here's what the
- MMC looks like to show the kind of UI we are talking about:
- </p>
- <center><img src="images/mmc.png"/></center>
- </subsection>
- <subsection name="Design Aspects">
- <p>
- A main application is required as a baseline where plugins can be
- snapped in. The main UI and the plugins should all be IoC enabled
- components. There will be initially two plugins: one to manage users
- and another to manage applications.
- </p>
-
- <p>
- Let's explore the application plugin. This plugin when selected
- will list the set of applications in the system within the
- table to the right hand side. If the plugin's node in the tree on the
- left hand side is expanded then all the applications are displayed in
- the tree. When application nodes are selected they display two
- containers: one for roles and another for permissions. When expanded
- the application node displays these two child nodes. When these nodes
- are selected the set or roles or permissions respectively are listed
- within the table to the right. Also when expanded these nodes display
- the roles or permissions respectively within the tree on the left.
- </p>
-
- <p>
- The user plugin will enable the management of users and user
- application authorization profiles. The plugin when expanded in the
- tree will list the set of users. When selected the table to the right
- will display these users as rows in the table. Users when expanded
- will display profiles for various applications in the system. Each
- profile will then display containers for the roles, grants and denials
- of permissions in the associated application for that profile.
- </p>
- </subsection>
- </section>
- <section name="Random Thoughts On Tree Based Navigation">
- <p>
- The main console application will need to expose access to its tree
- and table realestate. I have no idea on how this could be done right
- now. Perhaps its best to explore what a standard UI design would
- entail and then refactor that to use plugins. That's probably the
- best approach to weed out the better plugin based design.
- </p>
-
- <subsection name="Navigation Based on Database Metadata">
- <p>
- We need to build a tree model based on the contents of the database.
- Basically clicking on an application's roles tree node should list
- the roles in the application. We have a drill down mechanism with
- the tree to explore RMS contents. Not every node in the tree can be
- logically inferred or can it? Take for example the containers of
- objects like roles and permissions - can we infer the need to create
- the container for these objects that are of zero to many cardinality
- in relation to the application? They really can be but its a PITA to
- do this with reflection or reading the database's meta data to devise
- a generic navigation just for this small set of object types.
- </p>
-
- <p>
- For the heck of it let's just explore the idea of building a tree
- navigator that uses database metadata. Such a navigator must be given
- a set of seed tables. These seed tables are the child nodes right
- under the root of the tree. The metadata is used to determine the
- tables that have a foreign key to the seed table. For simplicity, let
- us automatically presume the cardinality of the fk relation to always
- be zero or more. This way every child table with a fk automatically
- represents a container node under the parent table. This container
- node will contain the records of the child table within it. The fk
- relations to the children will also be evaluated to determine their
- child containers as well.
- </p>
-
- <p>
- This sounding pretty cool now. Let's step through the events of
- exploring the application seed node. The application node is
- represented as a container with the label 'applications'. Expanding
- this branch node lists all the applications by name under it. These
- applications can in turn be expanded to display two child containers
- labeled, 'roles' and 'permissions'. Expanding the permissions
- container would list the set of permissions associated with the
- application. The permissions themselves are terminal and cannot be
- expanded. Expansion of the roles container displays the roles of the
- user. Now each role is referenced by a user profile but we do not
- want to display the user profile under each role or do we? Also roles
- have grants but these grants are a hunk of binary data that cannot be
- displayed appropriately using this scheme based on database metadata.
- A special editor is required to display the actual list of grants
- rather than this blob of binary data. These are the areas that are
- gray with respect to this technique.
- </p>
-
- <p>
- Furthermore we need a way to determine how to name container nodes and
- the labels of the records they use. A mapping is required to
- associate a container label for a table and a container child node
- label for each row in that table. The container label is easy. The
- container label map just says for table 'FOO', name the container
- 'Foos' and if there is an 'S' or 's' at the end of the table name then
- don't add the extra 's' for the container name. Now the child nodes
- in the container can be named using a map that specifies the column
- value to use as the container's unique name for the child node. So
- for a role the ROLE_NAME column could be used. In this case the value
- for the ROLE_NAME would be used to name the child node in the roles
- container.
- </p>
- </subsection>
- <subsection name="Navigation Based on Object Model Metadata">
- <p>
- This database metadata based navigation takes us to the records of
- interest. But keep in mind we really should not be dealing with
- database records or constructs at this point. We should be using the
- value objects created from the database.
- </p>
- <p>
- So then where does this leave us. Well we now have to deal with
- reflection to understand the containment heirarchy. The metadata
- we're looking for is now based on class and interface information
- which we use reflection to get to. This may actually be better for us
- because it reduces some of the complications of the database metadata
- based navigation above. For example the issue of flowing over into
- profiles because of a fk to the APP_ROLES table from the
- USER_APP_PROFILE_ROLES table is no longer there. The Role interface
- does not allow access to the profiles that reference the Role. Also
- the Role grants which are efficiently stored in the database as binary
- data no longer represent scaler quantities. They become containers
- that can reveal the set of permissions granted to the role or those
- that are associated with the role. So we actually gain more from the
- padding that reflection on interfaces gives us when building such a
- navigation system.
- </p>
-
- <p>
- There are however some problems that will result. The relationships
- between objects are often not so clear when container classes are
- used to return objects rather than using arrays of those class
- instances. Take for example return types using an Iterator. The
- type of the underlying objects returned is lost. We have to infer
- the type based on some naming convention or provide some extra meta
- information.
- </p>
-
- <p>
- Let's conduct the same exercise using reflection for navigation rather
- than using database metadata. Again some seed information is
- required for the first teir of child nodes under the root of the tree.
- When using database metadata the seeds were table names, which allowed
- the lookup of records in those tables when the container for the table
- was expanded. The seeds for reflection require a class or interface
- name as well as a factory like object for listing the set of objects
- that implement that interface. The RMS top level facade will be that
- factory but I don't think we should use that. Instead a new set of
- factories should be created to return these objects. Even for objects
- that are returned by the parent we should expose these 'factories'.
- Perhaps a 'factory' is not a good term for these objects that help
- operate on the containment trees of other objects. These peer
- factories or what ever could also provide extra hints and meta data
- not easily inferred through reflection regarding the composition of
- the class the factory is dedicated to. Basically the factory can
- either describe or clarify which functions to use to acquire child
- objects or a listing for them so reflection can proceed. The factory
- can also provide other things like menus and editors for child
- elements and so on.
- </p>
-
- <p>
- This route is sounding much better now. There is a well defined node
- type helper or container class defined (the helper factory thingy we
- talked about above). An instance of this class is registered for each
- data type involved in the containment hierary. Any objects that do
- not have registered helper containers for their classes or interfaces
- are deamed scalar objects and are not expandable as container objects.
- </p>
- </subsection>
- </section>
- </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <body>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>Rms Management Console Requirements</title>
+ </properties>
+
+ <section name="Rms Management Console Requirements">
+ <subsection name="UI Description">
+ <p>
+ The UI will be designed to resemble the Microsoft Management Console
+ (MMC) application. Snap-ins for the Rms console like MMC snap-ins
+ will have other snap-ins associated with them heirarchically. The
+ snap-ins and their heirarchy will be displayed like the MMC in a tree
+ on the left hand side of a split pane.
+ </p>
+
+ <p>
+ On the right hand side of the split pane plugins can display within a
+ table any information they would like. Basically selecting a plugin
+ node in the tree hands over control of this area to the right to that
+ plugin. The plugin may populate the table with what ever content it
+ needs as well as change the popup menus triggered on the cells of the
+ table.
+ </p>
+
+ <p>
+ On the tree display when expanding a plugin it is upto the plugin to
+ return the set of child plugins to display. Each subordinate plugin
+ when selected displays rows in the table to the right of the split
+ pan in accordance with the context of the plugin. Here's what the
+ MMC looks like to show the kind of UI we are talking about:
+ </p>
+ <center><img src="images/mmc.png"/></center>
+ </subsection>
+ <subsection name="Design Aspects">
+ <p>
+ A main application is required as a baseline where plugins can be
+ snapped in. The main UI and the plugins should all be IoC enabled
+ components. There will be initially two plugins: one to manage users
+ and another to manage applications.
+ </p>
+
+ <p>
+ Let's explore the application plugin. This plugin when selected
+ will list the set of applications in the system within the
+ table to the right hand side. If the plugin's node in the tree on the
+ left hand side is expanded then all the applications are displayed in
+ the tree. When application nodes are selected they display two
+ containers: one for roles and another for permissions. When expanded
+ the application node displays these two child nodes. When these nodes
+ are selected the set or roles or permissions respectively are listed
+ within the table to the right. Also when expanded these nodes display
+ the roles or permissions respectively within the tree on the left.
+ </p>
+
+ <p>
+ The user plugin will enable the management of users and user
+ application authorization profiles. The plugin when expanded in the
+ tree will list the set of users. When selected the table to the right
+ will display these users as rows in the table. Users when expanded
+ will display profiles for various applications in the system. Each
+ profile will then display containers for the roles, grants and denials
+ of permissions in the associated application for that profile.
+ </p>
+ </subsection>
+ </section>
+ <section name="Random Thoughts On Tree Based Navigation">
+ <p>
+ The main console application will need to expose access to its tree
+ and table realestate. I have no idea on how this could be done right
+ now. Perhaps its best to explore what a standard UI design would
+ entail and then refactor that to use plugins. That's probably the
+ best approach to weed out the better plugin based design.
+ </p>
+
+ <subsection name="Navigation Based on Database Metadata">
+ <p>
+ We need to build a tree model based on the contents of the database.
+ Basically clicking on an application's roles tree node should list
+ the roles in the application. We have a drill down mechanism with
+ the tree to explore RMS contents. Not every node in the tree can be
+ logically inferred or can it? Take for example the containers of
+ objects like roles and permissions - can we infer the need to create
+ the container for these objects that are of zero to many cardinality
+ in relation to the application? They really can be but its a PITA to
+ do this with reflection or reading the database's meta data to devise
+ a generic navigation just for this small set of object types.
+ </p>
+
+ <p>
+ For the heck of it let's just explore the idea of building a tree
+ navigator that uses database metadata. Such a navigator must be given
+ a set of seed tables. These seed tables are the child nodes right
+ under the root of the tree. The metadata is used to determine the
+ tables that have a foreign key to the seed table. For simplicity, let
+ us automatically presume the cardinality of the fk relation to always
+ be zero or more. This way every child table with a fk automatically
+ represents a container node under the parent table. This container
+ node will contain the records of the child table within it. The fk
+ relations to the children will also be evaluated to determine their
+ child containers as well.
+ </p>
+
+ <p>
+ This sounding pretty cool now. Let's step through the events of
+ exploring the application seed node. The application node is
+ represented as a container with the label 'applications'. Expanding
+ this branch node lists all the applications by name under it. These
+ applications can in turn be expanded to display two child containers
+ labeled, 'roles' and 'permissions'. Expanding the permissions
+ container would list the set of permissions associated with the
+ application. The permissions themselves are terminal and cannot be
+ expanded. Expansion of the roles container displays the roles of the
+ user. Now each role is referenced by a user profile but we do not
+ want to display the user profile under each role or do we? Also roles
+ have grants but these grants are a hunk of binary data that cannot be
+ displayed appropriately using this scheme based on database metadata.
+ A special editor is required to display the actual list of grants
+ rather than this blob of binary data. These are the areas that are
+ gray with respect to this technique.
+ </p>
+
+ <p>
+ Furthermore we need a way to determine how to name container nodes and
+ the labels of the records they use. A mapping is required to
+ associate a container label for a table and a container child node
+ label for each row in that table. The container label is easy. The
+ container label map just says for table 'FOO', name the container
+ 'Foos' and if there is an 'S' or 's' at the end of the table name then
+ don't add the extra 's' for the container name. Now the child nodes
+ in the container can be named using a map that specifies the column
+ value to use as the container's unique name for the child node. So
+ for a role the ROLE_NAME column could be used. In this case the value
+ for the ROLE_NAME would be used to name the child node in the roles
+ container.
+ </p>
+ </subsection>
+ <subsection name="Navigation Based on Object Model Metadata">
+ <p>
+ This database metadata based navigation takes us to the records of
+ interest. But keep in mind we really should not be dealing with
+ database records or constructs at this point. We should be using the
+ value objects created from the database.
+ </p>
+ <p>
+ So then where does this leave us. Well we now have to deal with
+ reflection to understand the containment heirarchy. The metadata
+ we're looking for is now based on class and interface information
+ which we use reflection to get to. This may actually be better for us
+ because it reduces some of the complications of the database metadata
+ based navigation above. For example the issue of flowing over into
+ profiles because of a fk to the APP_ROLES table from the
+ USER_APP_PROFILE_ROLES table is no longer there. The Role interface
+ does not allow access to the profiles that reference the Role. Also
+ the Role grants which are efficiently stored in the database as binary
+ data no longer represent scaler quantities. They become containers
+ that can reveal the set of permissions granted to the role or those
+ that are associated with the role. So we actually gain more from the
+ padding that reflection on interfaces gives us when building such a
+ navigation system.
+ </p>
+
+ <p>
+ There are however some problems that will result. The relationships
+ between objects are often not so clear when container classes are
+ used to return objects rather than using arrays of those class
+ instances. Take for example return types using an Iterator. The
+ type of the underlying objects returned is lost. We have to infer
+ the type based on some naming convention or provide some extra meta
+ information.
+ </p>
+
+ <p>
+ Let's conduct the same exercise using reflection for navigation rather
+ than using database metadata. Again some seed information is
+ required for the first teir of child nodes under the root of the tree.
+ When using database metadata the seeds were table names, which allowed
+ the lookup of records in those tables when the container for the table
+ was expanded. The seeds for reflection require a class or interface
+ name as well as a factory like object for listing the set of objects
+ that implement that interface. The RMS top level facade will be that
+ factory but I don't think we should use that. Instead a new set of
+ factories should be created to return these objects. Even for objects
+ that are returned by the parent we should expose these 'factories'.
+ Perhaps a 'factory' is not a good term for these objects that help
+ operate on the containment trees of other objects. These peer
+ factories or what ever could also provide extra hints and meta data
+ not easily inferred through reflection regarding the composition of
+ the class the factory is dedicated to. Basically the factory can
+ either describe or clarify which functions to use to acquire child
+ objects or a listing for them so reflection can proceed. The factory
+ can also provide other things like menus and editors for child
+ elements and so on.
+ </p>
+
+ <p>
+ This route is sounding much better now. There is a well defined node
+ type helper or container class defined (the helper factory thingy we
+ talked about above). An instance of this class is registered for each
+ data type involved in the containment hierary. Any objects that do
+ not have registered helper containers for their classes or interfaces
+ are deamed scalar objects and are not expandable as container objects.
+ </p>
+ </subsection>
+ </section>
+ </body>
</document>
Modified: incubator/directory/rms/trunk/gui/main/xdocs/rt.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/rt.xml (original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/rt.xml Mon Apr 12 09:39:28 2004
@@ -22,11 +22,11 @@
</li>
<li>
Brute force code will be faster to write and I can start taking notes
- as ideas come up about where to take the design.
+ as ideas come up about where to take the design.
</li>
<li>
- Can always refactor!
- </li>
+ Can always refactor!
+ </li>
</ul>
</subsection>
Modified: incubator/directory/rms/trunk/gui/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/maven.xml (original)
+++ incubator/directory/rms/trunk/gui/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/admin">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/admin">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/gui/xdocs/index.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/index.xml (original)
+++ incubator/directory/rms/trunk/gui/xdocs/index.xml Mon Apr 12 09:39:28 2004
@@ -16,7 +16,7 @@
<p>
RMC has already been built and documenation on it will be made
available soon. Hang tight and take a look at the UI snapshots
- <a href="./snapshots.html">here</a>.
+ <a href="./snapshots.html">here</a>.
</p>
</section>
@@ -29,7 +29,7 @@
<tr><th>Topic</th><th>Description</th></tr>
<tr>
<td><a href="./RMSAdminConsoleAndPlugins.doc">RMC Design</a></td>
- <td>Detailed design document on the RMS Management Console</td>
+ <td>Detailed design document on the RMS Management Console</td>
</tr>
<tr>
<td><a href="./ocmm.html">RMC OCMM</a></td>
@@ -37,15 +37,15 @@
The UI uses a special Object Containment Meta Model (OCMM) to
navigate the objects within the database and allow users of the
RMC to alter them. This section discusses the OCMM.
- </td>
+ </td>
</tr>
<tr>
<td><a href="./user-guide.html">RMC User Guide</a></td>
<td>
- Describes how to effectively use the RMS Management Console.
- </td>
- </tr>
- </table>
+ Describes how to effectively use the RMS Management Console.
+ </td>
+ </tr>
+ </table>
</section>
</body>
</document>
Modified: incubator/directory/rms/trunk/gui/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/gui/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -35,7 +35,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/gui/xdocs/ocmm.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/ocmm.xml (original)
+++ incubator/directory/rms/trunk/gui/xdocs/ocmm.xml Mon Apr 12 09:39:28 2004
@@ -1,15 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>RMS Management Console: Object Containment Meta Model</title>
- </properties>
- <body>
-
- <section name="Object Containment Meta Model (OCMM)">
- <p>
- Coming soon ...
- </p>
- </section>
- </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>RMS Management Console: Object Containment Meta Model</title>
+ </properties>
+ <body>
+
+ <section name="Object Containment Meta Model (OCMM)">
+ <p>
+ Coming soon ...
+ </p>
+ </section>
+ </body>
</document>
Modified: incubator/directory/rms/trunk/gui/xdocs/user-guide.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/user-guide.xml (original)
+++ incubator/directory/rms/trunk/gui/xdocs/user-guide.xml Mon Apr 12 09:39:28 2004
@@ -1,15 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>RMS Management Console: User Guide</title>
- </properties>
- <body>
-
- <section name="RMC User Guide">
- <p>
- Coming soon ...
- </p>
- </section>
- </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>RMS Management Console: User Guide</title>
+ </properties>
+ <body>
+
+ <section name="RMC User Guide">
+ <p>
+ Coming soon ...
+ </p>
+ </section>
+ </body>
</document>
Modified: incubator/directory/rms/trunk/jdbc/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbc/maven.xml (original)
+++ incubator/directory/rms/trunk/jdbc/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/jdbc">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/jdbc">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/jdbm/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbm/maven.xml (original)
+++ incubator/directory/rms/trunk/jdbm/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/jdbm">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/jdbm">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/je/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/je/maven.xml (original)
+++ incubator/directory/rms/trunk/je/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/je">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/je">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/je/xdocs/index.xml
==============================================================================
--- incubator/directory/rms/trunk/je/xdocs/index.xml (original)
+++ incubator/directory/rms/trunk/je/xdocs/index.xml Mon Apr 12 09:39:28 2004
@@ -1,114 +1,114 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>RMS JE Provider</title>
- </properties>
- <body>
-
- <section name="Justification">
- <p>
- RMS requires a simple yet fast database where the relationships
- between entities are known in advance. The database may be large
- in terms of the number entries per data type however the size of
- the data in bytes will be small.
- </p>
-
- <p>
- These requirements lead us to believe that the most optimal
- configuration for an RMS implementation is a custom database
- based on a btree implementation. Such an implementation would
- store data within B-Trees and associate keys programatically
- to establish relationships between entities.
- </p>
-
- <p>
- Searches would be extremely fast without the need for an interpreter
- and access would be in constant time regardless of the size of the
- database. Access to a local database file is required for such an
- implementation, hence some form of replication must exist to update
- the contents of files when changes occur to the master RMS store.
- The additional replication requirement occurs for all implementations
- and is not a big concern since the data set is small and the frequency
- of mutation is even smaller.
- </p>
-
- <p>
- JE is SleepCat's Java BTree implementation. Building an RMS provider
- based on JE is the target of this subproject.
- </p>
- </section>
-
-
- <section name="Design">
- <p>
- It would be most convenient to devise a set of interfaces around any BTree
- implementation so it can be swapped in and out. The biggest concern with
- such an approach are the differences between things like keys and the services
- they offer like transaction support and replication. Currently while
- writing this, there are two know BTree implementations. JDBM and JE from
- Sleepy Cat which is still in Beta. Later we may compare the two in depth however
- the point remains that some abstraction will be required to be able to swap one
- implementation in for the other.
- </p>
-
- <p>
- For the first run we don't intend to worry about these concerns. We will
- incrementally refactor both implementations until commonalities can be
- abstracted out of them. Until then we focus our attention to just using each
- BTree implemenation to the best of its ability.
- </p>
-
-
- <!--
- <subsection name="Table Abstraction">
- <p>
- Rather than call it a BTree we're going to use a simple lookup table
- abstraction. You use a key to lookup a blob of something. The underlying
- search mechanism may change to include things like skiplists which are
- probablistic BTrees. Regardless we want to hide the underlying mechanism
- and use a common denominator to access all implementations consistantly.
- </p>
-
- <p>
- A table uses a key to access a value. Two approaches have traditionally
- been taken: use an Object as the key or use a simple primitive type as a
- key. Obviously there is a speed verses flexibility tradeoff. Our take
- here is to use the cheapest key we can find and a primitive type is best.
- Some implementations may require the key to be wrapped and if so they pay
- the price instead of all implementations paying the price. Obviously the
- implemenations using the primitive type will have much less overhead.
- </p>
-
- <p>
- When primitive types are used associations require indices to correlate
- values.
- </p>
- </subsection>
-
- -->
- </section>
-
- <section name="Permission Map">
- <p>
- Applications manage a set of bit permissions within a bit vector. Each
- permission is associated with an application specific label and an index
- within the bit vector. Grants and denials are managed by setting the
- appropriate bits in the index to 0 or 1.
- </p>
-
- <p>
- An application defines the index at which a permission is located within
- a permissions vector. Permissions are looked up by application qualified
- names and by their index value. Point lookups for application permissions
- will not occur: applications will have their entire permission map loaded
- when they are loaded. The permission set and size is often not restrictive
- enough to warrent lazy loading on a per permission basis. With these facts
- in mind it makes sense to store an application's permissions in a raw binary
- format using the application name as the lookup key.
- </p>
- </section>
-
-
- </body>
-</document>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>RMS JE Provider</title>
+ </properties>
+ <body>
+
+ <section name="Justification">
+ <p>
+ RMS requires a simple yet fast database where the relationships
+ between entities are known in advance. The database may be large
+ in terms of the number entries per data type however the size of
+ the data in bytes will be small.
+ </p>
+
+ <p>
+ These requirements lead us to believe that the most optimal
+ configuration for an RMS implementation is a custom database
+ based on a btree implementation. Such an implementation would
+ store data within B-Trees and associate keys programatically
+ to establish relationships between entities.
+ </p>
+
+ <p>
+ Searches would be extremely fast without the need for an interpreter
+ and access would be in constant time regardless of the size of the
+ database. Access to a local database file is required for such an
+ implementation, hence some form of replication must exist to update
+ the contents of files when changes occur to the master RMS store.
+ The additional replication requirement occurs for all implementations
+ and is not a big concern since the data set is small and the frequency
+ of mutation is even smaller.
+ </p>
+
+ <p>
+ JE is SleepCat's Java BTree implementation. Building an RMS provider
+ based on JE is the target of this subproject.
+ </p>
+ </section>
+
+
+ <section name="Design">
+ <p>
+ It would be most convenient to devise a set of interfaces around any BTree
+ implementation so it can be swapped in and out. The biggest concern with
+ such an approach are the differences between things like keys and the services
+ they offer like transaction support and replication. Currently while
+ writing this, there are two know BTree implementations. JDBM and JE from
+ Sleepy Cat which is still in Beta. Later we may compare the two in depth however
+ the point remains that some abstraction will be required to be able to swap one
+ implementation in for the other.
+ </p>
+
+ <p>
+ For the first run we don't intend to worry about these concerns. We will
+ incrementally refactor both implementations until commonalities can be
+ abstracted out of them. Until then we focus our attention to just using each
+ BTree implemenation to the best of its ability.
+ </p>
+
+
+ <!--
+ <subsection name="Table Abstraction">
+ <p>
+ Rather than call it a BTree we're going to use a simple lookup table
+ abstraction. You use a key to lookup a blob of something. The underlying
+ search mechanism may change to include things like skiplists which are
+ probablistic BTrees. Regardless we want to hide the underlying mechanism
+ and use a common denominator to access all implementations consistantly.
+ </p>
+
+ <p>
+ A table uses a key to access a value. Two approaches have traditionally
+ been taken: use an Object as the key or use a simple primitive type as a
+ key. Obviously there is a speed verses flexibility tradeoff. Our take
+ here is to use the cheapest key we can find and a primitive type is best.
+ Some implementations may require the key to be wrapped and if so they pay
+ the price instead of all implementations paying the price. Obviously the
+ implemenations using the primitive type will have much less overhead.
+ </p>
+
+ <p>
+ When primitive types are used associations require indices to correlate
+ values.
+ </p>
+ </subsection>
+
+ -->
+ </section>
+
+ <section name="Permission Map">
+ <p>
+ Applications manage a set of bit permissions within a bit vector. Each
+ permission is associated with an application specific label and an index
+ within the bit vector. Grants and denials are managed by setting the
+ appropriate bits in the index to 0 or 1.
+ </p>
+
+ <p>
+ An application defines the index at which a permission is located within
+ a permissions vector. Permissions are looked up by application qualified
+ names and by their index value. Point lookups for application permissions
+ will not occur: applications will have their entire permission map loaded
+ when they are loaded. The permission set and size is often not restrictive
+ enough to warrent lazy loading on a per permission basis. With these facts
+ in mind it makes sense to store an application's permissions in a raw binary
+ format using the application name as the lookup key.
+ </p>
+ </section>
+
+
+ </body>
+</document>
Modified: incubator/directory/rms/trunk/je/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/je/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/je/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/jndi/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/jndi/maven.xml (original)
+++ incubator/directory/rms/trunk/jndi/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/jndi">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/jndi">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/jndi/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/jndi/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/jndi/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/project.xml
==============================================================================
--- incubator/directory/rms/trunk/project.xml (original)
+++ incubator/directory/rms/trunk/project.xml Mon Apr 12 09:39:28 2004
@@ -18,7 +18,7 @@
<url>http://incubator.apache.org/directory</url>
<issueTrackingUrl>
- http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400
+ http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515
</issueTrackingUrl>
<siteAddress>incubator.apache.org</siteAddress>
<siteDirectory>/home/akarasulu/public_html</siteDirectory>
Modified: incubator/directory/rms/trunk/spi/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/spi/maven.xml (original)
+++ incubator/directory/rms/trunk/spi/maven.xml Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-
-<project
- default="java:compile"
- xmlns:j="jelly:core"
- xmlns:u="jelly:util"
- xmlns:ant="jelly:ant"
- xmlns:maven="jelly:maven"
- xmlns:m="maven"
- xmlns:deploy="deploy"
- >
-
- <preGoal name="site">
- <attainGoal name="docbook:transform"/>
- </preGoal>
-
- <postGoal name="site">
- <attainGoal name="server:copy-images"/>
- <attainGoal name="subproject:collectdocs"/>
- </postGoal>
-
- <goal name="subproject:collectdocs">
- <ant:copy
- toDir="../target/docs/spi">
-
- <ant:fileSet dir="${basedir}/target/docs">
- <ant:include name="**"/>
- </ant:fileSet>
- </ant:copy>
- </goal>
-
- <goal name="server:copy-images">
- <copy toDir="target/docs/images">
- <fileSet dir="${basedir}/src/images">
- <include name="*.gif"/>
- </fileSet>
- </copy>
- </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project
+ default="java:compile"
+ xmlns:j="jelly:core"
+ xmlns:u="jelly:util"
+ xmlns:ant="jelly:ant"
+ xmlns:maven="jelly:maven"
+ xmlns:m="maven"
+ xmlns:deploy="deploy"
+ >
+
+ <preGoal name="site">
+ <attainGoal name="docbook:transform"/>
+ </preGoal>
+
+ <postGoal name="site">
+ <attainGoal name="server:copy-images"/>
+ <attainGoal name="subproject:collectdocs"/>
+ </postGoal>
+
+ <goal name="subproject:collectdocs">
+ <ant:copy
+ toDir="../target/docs/spi">
+
+ <ant:fileSet dir="${basedir}/target/docs">
+ <ant:include name="**"/>
+ </ant:fileSet>
+ </ant:copy>
+ </goal>
+
+ <goal name="server:copy-images">
+ <copy toDir="target/docs/images">
+ <fileSet dir="${basedir}/src/images">
+ <include name="*.gif"/>
+ </fileSet>
+ </copy>
+ </goal>
+</project>
Modified: incubator/directory/rms/trunk/spi/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/spi/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/spi/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../../mailing-lists.html"/>
<item name="License" href="../../../license.html"/>
Modified: incubator/directory/rms/trunk/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/xdocs/navigation.xml (original)
+++ incubator/directory/rms/trunk/xdocs/navigation.xml Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
<menu name="Resources">
<item name="IRC" href="../../irc.html"/>
- <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+ <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
<item name="Lists" href="../../mailing-lists.html"/>
<item name="License" href="../../license.html"/>