...
Susan: There are aspects of configuring uPortal that you have to run uPortal in order to change it.
[some discussion]
uPortal 3 In-Place Configuration
by Eric Dalquist
Eric: We should be able to state things as XML, drop in some designated directory, and when uPortal starts up it would notice the file and do what it says. There will eventually be no 'dbloader' it will work this way instead.
...
Faizan: I will email code to Andrew. [Faizan has since done so and, predictably, Andrew hasn't had time to do much with this code. It needs to get out into public source control for collaboration, so that others can pick up the torch, so that people motivated by need can run with it. ]
Return to discussing uPortal 3 status
Eric: We did RC1 before the last meeting, there were serious issues. we addressed some of them. There was a release last Friday, "Milestone 4". Still has some bugs so not quite good enough for RC2.
...
Eric: For the summer conference, (tentatively "RC2"), from most likely to least likely by then:--
- restructuring the Hibernate DAO's, could be rather simpler; simplifying our registry logic regarding that
...
- taking what we get out of our XML talks and implementing db import/export so we can get rid of dbloader. domain-specific XML info (GAP, etc.)
...
- hopefully what people want out of the box. We haven't tested all the different group stores yet.
...
- how about an integrated LDAP server (via Apache?).
...
- drop-in configuration of a portal.
The first two Eric feels have to be done, the rest he would like to be done before the conference. -- he wants to cut the release about a week before.
...
It's a pain to have to tinker the configurations and upgrade the database.1..
- Should not have an independent app to tinker the db. All should go through the standard DAO's.
...
- Object re-use -- use the existing read and write code
...
- There should be a migration path between dot releases.
...
- Should run from command line without running portal, and from the web UI.
...
- Should have varying granularity, a single object, group of objects or the entire database.
...
- XML format easily human readable or writable
...
- Have schemas for all the tables so XML editors will nicely edit them.
...
- Include an object model version number so XML will read earlier versions.
...
- A way to reference other objects in the same XML file or other XML files already in the system. This is the hardest question Eric has about how to do the export/import.
...
- DAO implementation agnostic.
...
- -- don't include database specific keys in the export, and shold not be needed in the input XML.
...
- Functionality should work for all portal domain objects including: users, portlet domain objects (6 different objects), groups and layouts.
[morning break]
Eric: Export/import isn't so much "actions" (move channel from group a to group b) but more a different representation of the data. Sort of object serialization.
...
Eric: What do we need to include?--
- layout information; depends on what LM you are using; primarily the user's layout.
...
- layout fragments; kind of the administrative kind of layouts.
...
- objects: there are some things that are channel definitions, but there are several that are not channels. how does this work if you only want to export a few of them.
...
- portlet group object
...
- local group information
...
- local permission information
...
- user account information
...
- Group and Permission information.
(Dan: there are bunches of things that are not handled by the portal framework.) (Data in the local store may reference things in other stores; especially the permissions table) (Eric: exporting the PAGS group information isn't similar to other tables; it's rules rather than users or channels) (Dan: there's an implied plan to persist the PAGS rules in the database, so you have to serialize them as well as the explicit memberships in the local group store) (Eric: having an XML schema that fits into the export/import scheme would make the exporting and importing just work)
...