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/ )
* 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?
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.
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
(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.
Stephen
At 10:10 AM 2/12/00 -0500, you wrote:
>
>On Sat, 12 Feb 2000, Kevin A. Burton wrote:
>
>> Jeff Prickett wrote:
>> >
>> > Kevin,
>> > Hello, I was wondering if you could update us here on the list about
>> > calendaring/project code and if this functionality should be in Jetspeed.
>> > Thanks to another member of the list Sandy's project stuff has a
temporary
>> > home.
>>
>> +1. Yes it should be in JetSpeed. Hopefully integrated via the
>> plugin/portlication infrastructure. As an FYI I think most JetSpeed
>> code should be done this way.
>>
><snip>
>
>Thanks for the reply. I will get the package structure reorganized to
>jetspeed. What do you think of org.apache.jetspeed.icalendar? I will send
>it to you later today or early Sunday.
>
<snip>
>
>5. Write a calendaring client. Maybe this one is too ambitious and it
>might not fit in with the java.apache.org site, ie server applications.
>
<snip>
>
>Jeff Prickett
>[EMAIL PROTECTED]
>
--
--------------------------------------------------------------
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]
