...

• A. Soroka 
• David Wilcox 
• James R. Griffin III
• Aaron Birkland 
• Stefano Cossu  
  
• Unknown User (daniel-dgi) 
  
• Andrew Woods
• Yinlin Chen  
• Jared Whiklo
• Doron Shalvi
• Unknown User (acoburn)
• Kevin S. Clarke
• Bethany Seeger
• Nick Ruest

Agenda

1. OSGi:

   No Format
   fcrepo-kernel -> fcrepo-kernel-api fcrepo-kernel-impl -> fcrepo-kernel-modeshape

   Standard practice with OSGi bundles is that any package with "impl" or "internal" is not exported.

2. 4.3.0 Release planning

   1. Outstanding items? 

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1532

      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1630

3. NonRdfSource properties - where should they live?

   • 2015-06-08 - Open Repositories Committers Meeting

   • https://jira.duraspace.org/browse/FCREPO-1540

   • https://jira.duraspace.org/browse/FCREPO-1590

   • https://jira.duraspace.org/browse/FCREPO-1411

4. F4 core, extras, and labs (mailing list thread)

   1. What are the "core" Fedora capabilities/projects?
   2. Which projects are always included in any given release?
   3. Should we decouple the version number schemes of optional projects from core releases?
      1. A. Soroka: Yes, there is no advantage to locking them.
   4. Should optional projects share the same "org.fcrepo" package namespace?
      1. A. Soroka: Only if the responsibility for them is the same as the responsibilities for core (that is, owned by the same people and accompanied by the same promises)
   5. What are the criteria for graduating from (1c)? - Practices from Islandora? Hydra?
   6. What is the policy for deprecating a project from (1a) or (1b)?
   7. What should the name of a third GitHub organization be, if such an organization is needed?
      1. fcrepo-extras
      2. fcrepo-ext
      3. fcrepo-flaky
      4. fcrepo-chum-bucket

5. ...

6. Current Priorities

   Expand

   Performance Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1609 Single subject Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1474 Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1540 Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1447 Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1411 fcr:metadata as a container Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1590 Point-like objects Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1470 Camel RDF serializer Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1519 Migration-utils Wait for Mike Bugs Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

7. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

8. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

• Welcome Bethany Seeger - Library dev at Amherst, working with A. Coburn

1. Service provider

1. OSGi:
   1. The decision is made on the changing Fedora package names. Fedora users/clients should not be impacted on it. However, software built around Fedora will be impacted.  
2. 4.3.0 Release planning
   1. Release 4.3.0 next week. Nick is the release manager. Andrew and Nick will meet on next Friday and proceed 4.3.0 release. People who want to do future Fedora release can contact Andrew.
3. NonRdfSource properties
   1. After discussion, decide to internally store the properties presented as triples in fcr:metadata on the NonRDFSource being described (as opposed to on the fcr:metadata-backing resource). 
   2. [IRC discussion]
      1. ajs6f: I claim that this won't prevent us from doing whatever we want with fcr:metadata later (making it a container, making it have a special lifecycle, filling it with peanut butter and Valvoline and baking it for several hours in a turtle shell, whatever we want).
      2. escowles: i'm fine with storing the properties on the nonRDFsource -- that makes sense since they are about that resource and i'm actually fine with retrieving fcr:metadata and getting triples about the nonRDFsource -- I think it was barmintor who was most concerned with the repository URL and the subject URI being the same
      3. awoods: I think there is good reason for concern about a mismatch between the repository URL (binary/fcr:metadata) and the subject URI (binary)... but there does not appear to be a better solution at the moment.
      4. escowles: i agree -- too many operations required by the binary and its description for them to peacefully coexist at the same rest api URL
4. F4 core, extras, and labs
   • F4 GitHub Organizations
   1. F4 core capabilities: Repository CRUD, Transactions, Versioning, Authorization, and Fixity. 
   2. Included in any given release: Fedora reference impl. 
      1. Could be accompanied by a compatibility matrix for non-core modules along the lines of: http://docs.sonarqube.org/display/PLUG/Plugin+Version+Matrix
   3. Decouple module versioning? 
      1. yes. seems everyone agrees with it. 
   4. Continue discuss 4.d in next week meeting. 
5. 1. Elliot + Aaron - moving conversation forward soon
   2. Initial proposal/sketch has been provided to the community
      1. not quite a proposal, need more community involvement and requirements
   3. Goals of effort:
      1. Add capability through community contribution

      2. Collaboration across islandora/hydra

         • common service layer
         • similar to pcdm
         • security layer
         • including indexes
         • support for content modeling
   4. Effort will be launched in early fall
      1. Call for participation: stakeholder, reviewer, developer
   5. Stefano motivated to move the forward
6. fcrepo-webapp in fcrepo4
   1. Esme: it would be nice to have one project: more coherent releases, less confusion; however demoting frepo-webapp may not make sense
   2. Adam: the only reason we have webapp-plus is because of unfortunate mix of configuration and wiring. Ideally we would have one deployable artifact for both 
   3. Danny: agree; expect to have a deployable and configurable artifact. I should be able to enable specific features, not an all-or-nothing deal. 
   4. Andrew: We have 2 possibilities: 
      1. OSGi, which offers a high degree of runtime configurability
      2. externalizing components and make them more configurable than current ones
   5. Adam: there is a difference between configuration (how you make your components work) and wiring (which components you enable). Those are combined in F4, due to Spring XML which is not the ideal tool for this job. We use Maven to ameliorate the problem instead of solving it.
      
   6. Andrew: Webapp-plus is mostly wiring
   7. Adam: That is because Modeshape owns so much configuration; there has been extensive discussion about unpacking that config
   8. Aaron B: Regarding API extension arch: as far as implementation, we would design it as modular as possible - that is conceptualized and outside of Fedora, not dealing with Modeshape stuff. We need to discuss how to approach modularity; also how to live with specific Modeshape config
   9. Adam: you need to configure Modeshape options somewhere to enable any of the webapp-plus modules
   10. These modules cannot do their thing via a client?
   11. Adam: No, unless you want to run them on pure LDP (HTTP) - and performance would suffer
   12. Andrew: confirm that auth modules are relying on Modeshape because they pass through it before they are delegated to our custom module 
   13. Andrew: Back to the original question: is there anything that we can focus our energy on to improve the way we have wiring and config in one?
   14. Adam: There are some options: 
       1. Configuration: OSGi, very powerful and not too hard to configure - there are some standard patterns on how to store config. Also there could be custom config containers, like config files or storing config in the repo itself
          
       2. Wiring: For micro-level wiring, there is CDI, or there are OSGi services; Spring can even do wiring with some care to avoid mixing in config. for module level wiring, OSGi is the best - maybe Java 9 (Jigsaw)
          
   15. Danny: We are about to push out an OSGi deployment but not many have the resources to do that
   16. Adam: there is a difference between OSGi frameworks and containers. You can put OSGi in containers (e.g. Apache Karaf or Eclipse Virgo). You can also put an OSGi framework (like Apache Felix or Eclipse Equinox) into a different kind of container, like a servlet container. Either will support an OSGi-ified Fedora. The hard part is actually the OSGi-fication part, which is a lot of work
   17. Aaron C: leaving webapp where it is is fine; the question is moving toward OSGi which happens step by step. Once there, deployment will be more flexible. Rather than expending resources in figuring out how to separate current webapps we should focus on how to move to OSGi
   18. Andrew: seems like there is a recognition toward moving OSGi - let’s put together a plan
   19. Aaron C: Not everyone knows what OSGi is and what it can do; we can explain that and what those incremental steps are to make Fedora deployable as OSGi
   20. Aaron will create a page on the Wiki and inform the community
7. core, extras, labs:
   1. There is consensus on having three separate Github organizations: fcrepo, fcrepo–labs, and fcrepo-extras.