Stephen Adkins wrote:
>
> Hi,
>
> QUESTIONS (please read background before responding)
>
> * Would it be a help if I started a Functional Requirements
> document for the JetSpeed groupware stuff?
> (at http://www.officevision.com/pub/jetspeed/ )
That might be a start. I wouldn't go crazy on it though. In OSS areas
I think that too much talk can be a bad thing. Goes with the release
early, release often thing.
> * Can we bounce around some proposals of what the package
> structure should be in the medium-term?
> * Should this structure follow some of the conventions
> for the "om" (object model) package reorganization
> being discussed on the turbine list?
I still have to read this thread.
> Stephen
>
> BACKGROUND
>
> It sounds like Jeff has done a lot with calendaring
> and Sandy has done a lot with project/task management.
> Jeff suggested a new package that his calendar code would
> be in and has volunteered to help additionally on Turbine-
> integration with Sandy's code.
>
> Currently, the package structure for JetSpeed is
>
> package org.apache.jetspeed.admin;
> package org.apache.jetspeed.calendar.simplestore;
> package org.apache.jetspeed.calendar;
> package org.apache.jetspeed.messaging;
> package org.apache.jetspeed.portal.portletmarkup;
> package org.apache.jetspeed.portal.portlets;
> package org.apache.jetspeed.portal.servlets;
> package org.apache.jetspeed.portal;
> package org.apache.jetspeed.test;
> package org.apache.jetspeed.util;
> package org.apache.jetspeed.xml.cache;
> package org.apache.jetspeed.xml.providers.impl;
> package org.apache.jetspeed.xml.providers;
> package org.apache.jetspeed.xml.rss.abstraction;
> package org.apache.jetspeed.xml.rss.downlevel;
> package org.apache.jetspeed.xml.rss;
> package org.apache.jetspeed.xml.subscriptions;
> package org.apache.jetspeed.xml;
> package org.apache.jetspeed;
>
> I derived this simply by executing
>
> grep '^package' $(find org -name '*.java' -print) | sed -e 's/.*://' |
> sort -u
>
> on the source tree.
> Jeff suggested the addition of
>
> package org.apache.jetspeed.icalendar;
>
> How does this relate to the reorganization of Sandy's source code
> or integration with turbine? Currently, she uses only one package
>
> package org.apache.jetspeed.project;
>
> She has the following classes all in that same package
>
> org/apache/jetspeed/project/Organization.java
> org/apache/jetspeed/project/Project.java
> org/apache/jetspeed/project/Timesheet.java
> <others, utility classes, etc.>
>
> Among other things, she mentions the following future or current
> functionality
>
> projects, tasks, clients, contacts, employees, notes sections
> for each, allowing for discussion groups, etc.
Off hand these should probably be in their own package.
> It seems to me that if we want to make a separate package for
> each major contributor, that is certainly a way to manage the
> code in the short term.
>
> However, in the longer term, I would propose that the package
> structure (and the identification of business object classes)
> be driven by a bigger vision of where the functionality is going.
> (i.e. The design should be driven by a statement of the
> functional requirements. what a concept...) ;-)
>
> I would volunteer to produce and maintain such a functional
> requirements document, unless someone else who has more history
> with this project would like to do it or unless someone thinks
> this is a bad idea. I would clearly need contributions from
> all of you who have ideas already of what the requirements are
> (and what requirements/features the code already implements).
>
> I would probably start by collecting what is already implemented,
> add the essential requirements satisfied by MS Outlook, and
> then add some of my own ideas that I have a particular interest
> in helping implement.
>
> As far as conventions go, the members of the Turbine list have
> been discussing a reorganization of the packages within Turbine
> to reflect that some of the classes actually implement business
> objects, and they should go in a "logical package" (think UML)
> under an "om" (object model) package. A subset of the proposed
> Turbine packages is listed below.
>
> org.apache.turbine.om
> org.apache.turbine.om.peer
> org.apache.turbine.om.user
> org.apache.turbine.om.user.peer
> org.apache.turbine.om.security
> org.apache.turbine.om.security.peer
> org.apache.turbine.util
> org.apache.turbine.util.db
>
> Perhaps a standard for Turbine applications could be to include
> the following package structure.
>
> org.apache.<appname>.om
> org.apache.<appname>.om.<logicalpackage>
> org.apache.<appname>.om.<logicalpackage>.peer
> org.apache.<appname>.util
> org.apache.<appname>.util.db
>
> In this spirit, the project management and calendaring functionality
> might be integrated into the following package structure.
>
> org.apache.jetspeed.om
> org.apache.jetspeed.om.project
> org.apache.jetspeed.om.project.peer
> org.apache.jetspeed.om.calendar
> org.apache.jetspeed.om.calendar.peer
> org.apache.jetspeed.util
> org.apache.jetspeed.util.db
Interesting thoughts... will have to think about this one.
> (Or maybe calendaring is in fact part of the "project" package.)
>
> Hopefully the utilities classes, persistence mechanisms, and login
> screens can all eventually be rethought over time as part of
> Turbine integration.
>
> P.S. Jeff, I think that the "calendaring client" that you mention
> below (if it is servlet/HTML-based) is certainly not too ambitious
> for the project.
<snip>
Hm. Yes. If it is based on web technologies then it is totally a
java.apache project. :)
--
Kevin A Burton
http://relativity.yi.org
Linux - The revolution will NOT be televised
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
