The purpose of this meeting was to formulate, discuss, and prioritize the major Fedora development items for 2010, and to start identifying who can help make them happen.
It was held in the Franklin-Wilkins Building on the Waterloo Campus of Kings College, London, Feb 23-24.
Based on a poll of attendees, the agenda focused on the following major topics:
Asger presented an overview of the Enhanced Content Model work, and we discussed which parts made sense to fold into the core Fedora distribution. The discussion focused primarily on the extension mechanism and schema + relationship validation.
The group agreed that the following would be good to fold into the core distribution:
An extension mechanism for DS_COMPOSITE_MODEL, inspired by ECM's Use of this extension mechanism to:
The ability to validate XSD and OWL on-demand (after ingest) The ability to clone objects via Fedora's APIsThe following need further discussion:
Ability to validate XSD and OWL as prereq. to "Active" state transition Kai indicated interest in defining DSL(s) for validationTo drive this work forward, we identified:
Lead: Asger
Contrib: KaiBen led a discussion of some of the outstanding issues with SDefs and SDeps, suggesting several improvements in addition to what has been documented in JIRA.
The group agreed that the following would be good to have in future versions of Fedora:
The ability to support multiple bindings in service deployment WSDL. Action: Create a JIRA issue for this Support for POST/PUT/DELETE object methods (front-end) Support for POST/PUT/DELETE method bindings (back-end) Support for SOAP method bindings (back-end)We did not have time to discuss everything noted in the document, but the general consensus was that a rehaul of the way the service deployment code works in Fedora (versus small, incremental code changes) will probably be necessary to get us where we want to go.
To drive this work forward, we identified:
Lead: Ben Contrib: AsgerWe had planned on discussing Asger's proposal for adding datastream methods to Fedora, but decided to discuss this later in the interest of time.
Eddie kicked off a discussion on what we've learned with OSGi so far, and Bill and Andrew shared some of their OSGi experience with DuraCloud.
The idea with the first chunk of our Fedora-OSGi work was to a) prove that Fedora can be packaged as a complete OSGi bundle, and b) begin OSGi-fying some of the key pieces that Fedora uses under the hood. To that end, Eddie experiemented and had some success with building Fedora as an OSGi bundle, and started doing the same for Mulgara. Chris successfully changed Akubra's plugins to be OSGi bundles and has gained experience in making existing artifacts OSGi-friendly.
Bill and Andrew are actively using OSGi for the "service" portion of DuraCloud, but noted that there is a significant learning curve and a new set of dependency issues to be concerned with, similar to the "growing pains" we experienced in the transition to Maven.
Those of us with some OSGi experience agreed that OSGi still represents a promising direction for Fedora, but there are still a lot of hurdles to getting there. Like maven, these hurdles will become shorter with time, as Java-OSGi adoption increases and the community around it grows.
During this discussion, we noted again that moving toward OSGi is not incompatible with using Spring for dependency injection. The latter seems to be a more tractable goal for the time being, with more immediate payoff. We agreed to:
Document best practices for being "OSGi Friendly" In the short-term, move to Spring for dependency injection (Fedora modules = spring beans) Keep the long-term goal of having a Fedora OSGi bundle that can be used by other appsTo drive this work forward, we identified:
Chris Dan, Andrew, AsgerAaron
Steve
Kai
|
|
|
|
|
Session lead: Thorny
|