MPDL AB Meeting 2009-04-01

MPDL  Restricted Access to MPDL
 * Participants:Thomas Endres, Michael Franke, Tobias Schraut, Wilhelm Frank, Natasa Bulatovic

PubMan Ingestion

 * see Talk:PubMan_Ingestion

Outcome

 * all agree it's faking of a workflow engine (no time to test/implement in R5)
 * each ingestion task will be an item (with originally uploaded file as component)
 * processing log will be created separately in a database
 * after processing is finished (successful or not) processing log will be moved to the item and database data will be deleted
 * ingestion task-items will be created immediately when user starts the import
 * MyImports will be available for Depositors
 * My imports will also be available for Moderators (to see running imports in their collection)
 * Users will have to explicitly decide if all-or-any rule applies (GUI change on Ingest screen)
 * any: this means, that if 1000 items were to be ingested and 998 were successfull, users will have less 2 items
 * all: this means either all 1000 items are successfully created or none
 * Users will have to explicitly decide if email should be sent upon ingestion or not (check-box send email notification (de)selected by default) - GUI change on Ingest screen
 * Statuses: successful (no warnings, with warnings), unsuccessful (problem?, error?), tbd by Michael
 * e.g. successfull (not all items validated successfully for release)
 * e.g. partly (in case of "any" rule: ingestion was successful for 999 items)
 * Ingestion task statuses reflect only creation of items (not the status of batch release or submit which is separate task)
 * Import and ingest are two separate functions (import is single item and ingest is multiple items)
 * in case of Import item is not created, it is only re-mapped and displayed on the screen
 * in case of Ingest items are created

Read only PubMan

 * http://zim01.gwdg.de:8080/browse/AS-735

Outcome

 * Edit links can be disabled based on a property change, or not allowed
 * Users should be able to log-in and make their searches and filters
 * Users should not be able to create new items or modify existing items
 * issue resolution should be valid for all solutions
 * issue resolution should be based on a kind of interceptor of all editing links
 * property for mode i.e. "normal", "maintenance", etc.
 * in any case if the system is not functional (i.e. no functionality of PubMan is not there) - extra out-of-service page should be displayed to the end user
 * to be checked further

Deployables and Jboss

 * Behavior of the postgresql driver ( no unlink to the database after redeploy )
 * Copy the postgres jar to JBoss' lib directory instead of delivering it with the pubman ear
 * Write something that manually unloads the driver when hot deploying
 * Disallow hot deployment
 * Migrate the CoNE database to Hypersonic. JBoss knows Hypersonic by default, so no extra driver would be required. Con: I have not much experience with HSQL and cannot judge performance and stability.
 * Delete the JNDI datasource and build up the JDBC connection from inside the code. This is a little less conforming to JavaEE standards but I can see no real disadvantage.
 * Isolation of ears running on one jboss (possibility to run several solutions on one jboss)
 * Dependencies between deployed ears (pubman -> coreservice in deploy phase)
 * Expected outcome: Find a deployment structure (classpath isolation; bootup order) on jboss which covers actual and future needs

Going Productive

 * Discussion on necessary steps for R5 (see http://colab.mpdl.mpg.de/mediawiki/ESciDoc_Solutions_Going_Productive)
 * Planning a meeting with all involved groups

Solution development

 * discussion on pubman deployment and how to approach it
 * discussion on solution properties and how to approach it
 * discussion on service locator issue and how to approach it
 * discussion on development of own policy templates and checking the possibilities to define policies on our own
 * background: more roles coming up with further solution developments
 * see also Talk:ESciDoc_Solutions_summary

Definition of TODOs for AB

 * scope: until March 2009
 * Proposal: have JIRA project for AB tasks only not to loose track of

EA Documentation

 * issues with the documentation
 * presentation of EA Documentation

Authoriziation issues

 * check http://zim01.gwdg.de:8080/browse/AS-381

Presentation test suite / test cases

 * What to test?
 * page flow
 * CRUD of items
 * FT upload
 * genre specific test cases
 * page behaviour (field/group presentation)
 * logic behaviour (save, cleanup)
 * simple or sophisticated item creation (using list elements -> i.e. create more than one creator, or not?)
 * search tests possible?
 * Javascript Tests?


 * Maintenance and creation of tests
 * who will create tests
 * who will maintain them?
 * is a graphical test creation (i.e. browser based) necessary?