------------- Release notes ------------- Quickstart 2.2 --- February 2005 Includes calendar release 2.2, in subdirectory calendar2. Many bug fixes, particularly to fix Locale and JavaBean problems which were causing failures on certain JVMs (often, Windows). Attempt to make it compatible with Java 1.5. Haven't tested yet. Preliminary work to make it work with SyncML and as a JSR 168 portlet --- thanks to Xavier Lawrence and Jahia. Much better support for these features should be available in 2.3, which should be coming soon. Unit and other tests added. Database dump/restore facility. Quickstart 2.0 --- ?, 2004 Includes calendar release 2.0, in subdirectory calendar2. Restructured to highlight major components. Switch logging to log4j - see notes above. RPI struts + xml + xslt based applications distributed in the place of the original UW clients. Quickstart 1.3 --- January 27, 2004 Includes calendar release 1.3, in subdirectory calendar. Moved from using JDBC drivers to more modern 'DataSource' implementation. To get this to work, upgraded Tomcat to version 5.0.16, which requires Java 1.4 Export function has been expanded, and is easily accessible via the public events entry menu. All events are now cached when the webapp is started, which means public events you enter won't show up in the public calendar (or possibly the private calendar, if you started that before you entered the event). You can see them by stopping and restarting Tomcat. A better caching mechanism should be included in the next release. More CAP functionality. Minor bug fixes. Quickstart 1.2 --- September 2, 2003 Includes calendar release 1.2, in subdirectory calendar. Includes subscriptions to public calendars, and a reworked version of public calendars. Calendars are now stored in the database. If you use another database, you should run java edu.washington.cac.calendar.db.LoadCalendars where should be a file that looks something like calendar/resources/calendar/initialCalendars Includes an embryonic CAP server (see directory calendar/src/edu/washington/cac/calendar/cap). This release also officially changes the fields 'public' and 'create' to 'publicf' and 'created' in all databases, and renames the 'authorization' table to 'auth', to avoid clashes with SQL reserved words. Quickstart 1.1 --- February 7, 2003 Includes calendar release 1.1, in subdirectory calendar. Includes a much improved public events display system. It's still rather UW-centric, but you should be able to get the idea. Log in as a generic user who can enter public events, and enter some events. Then log in as guest and browse. Note: because there is no real authentication mechanism with the quickstart release, adding a public event to your personal calendar (available by clicking on an icon in the public events display application) will not work *unless* you have first logged in to the personal calendar as one of the three toy users. I found that if I tried, tomcat complained about an obscure NullPointerException. There is also support for some recurring events, but no way to add them through the web interface. At the UW, we add the schedule of classes to the database using a separate process, and these are, of course, recurring events. Send e-mail if you're interested in hearing more. Quickstart 1.0.1 --- August 26, 2002 Bugfix release to support mysql. Contains calendar release 1.0.1 in subdirectory 'calendar'. * Unfortunately named 'create' field can be renamed. * Will work with databases like mysql that don't support subqueries. See the documentation for db.properties in calendar/docs/HOWTO Quickstart 1.0 --- July 24, 2002 Includes calendar release 1.0, in subdirectory 'calendar', which contains a useful ant build.xml and build.properties file. You can now change things, recompile, and redeploy. Includes the public events entry application. This application is currently very UW-centric, but per the dictates of open source, I'm releasing early anyway. Pubevents: What works --------------------- You can add events. Once you have, you can see them by logging into the personal calendar as guest. Think of the guest view as the public events display app. As a public events administrator, you can edit or delete other people's events, and authorize other users to add public events, or to be an administrator. Pubevents: What doesn't work ---------------------------- I purposely left out the markedevents and redalerts tables, because one of the next steps is a database reorg that will remove these tables. As a side effect, the functions 'Extract Data for University Week' and the Alerts functions on the administrator's menu don't work well or at all. Given these functions are particularly UW-centric, I'm hoping this won't matter. Pubevents: What sort of works ----------------------------- Deleting a public event gives an error message about markedevents. If you only delete one event, the message can be ignored; the delete succeeded. I haven't tested the case where you delete multiple events.