Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
Attendees
Agenda
- Islandora/F4 update
- Prioritize tickets for sprint starting Monday
- F4 and Java8
- Moving fcrepo-camel from labs
- Transform
- Fedora 4.x documentation space
- Recent mailing list threads
Minutes
- Islandora/F4 Update
- Project will commence Monday (project plan)
- A couple weeks to lay out project goals on Wiki
- A fedora 4 interest group will be relaunching soon as the rallying/staging point for this project
- Goal is to have a working islandora site where you can view 4.x repo that was migrated from a 3.x by Open Repositories
- Prioritize tickets for new sprint
- Maintenance sprints will continue as well as feature-focused sprints
- Andrew Woods suggested we look at the list and reorder it as we saw fit
- Unknown User (escowles@ucsd.edu) said the order seemed pretty good
- In request to clarification, a "story" type in Jira is a "feature, modification or enhancement" as opposed to something that's broken.
- Move to Java 8
- Can institutions support Java 8?
- What is our strategy going forward... will we adopt new versions X months after release?
- Unknown User (escowles@ucsd.edu) said he didn't anticipate problems
- Michael Durbin expressed an opinion towards being conservative and not forcing updates to Java to get Fedora Updates
- Doron Shalvi wanted to ensure that the we should prioritize being able to run on the current (NOT EOL) version of Java
- There was a general consensus that we compile down to the oldest non-EOL version of the JVM.
- When Java 7 is no longer supported, we start compiling to Java 8 and can use features that would prevent Java 7 compatibility
- In other words, Fedora 4.x will run on any current (not EOL) version of Java
- A. Soroka: My understanding was that Fedora 4.x will run on only the latest non-EOL Java version, not any non-EOL Java version.
- Andrew Woods will draft a version of this policy and distribute it out on the list
- We will also make a JIRA ticket to enforce this in the build
- fcrepo-camel project
- this project represents a framework on which one could easily build the functionality of the fcrepo-message-consumer project
- to graduate from fcrepo-labs it needs
- sufficient test coverage
- modules follow release version numbers
- Michael Durbin asked how it differed from jms-message-consumer
- It's at a lower level
- the message consumer exposes an API to allow rebuilds
- camel allows you to implement a set of routes (in maybe 10 lines of code) to do all of those things
- instead it provides a framework
- Could rewrite fcrepo-message-consumer to use fcrepo-camel in 20-30 lines of code
- Stefano Cossu is already in the process of implement a triplestore indexer based on fcrepo-camel
- Andrew Woods concurred that this should be moved out of labs, and that we should look at what's left before deprecating jms-message-consumer
- Unknown User (acoburn) indicated that he would want a full pre-packaged implementation that can be deployed in a servlet container (as well as OSGI) with jms-message-consumer's functionality before deprecating it
- Unknown User (acoburn) wondered if we'd want those to be in the same git repo, or elsewhere... and said he'd probably prefer these start as examples documented or packaged inside of fcrepo-camel rather than standalone for now.
- fcr:transform question: when you have a parent, child and binary, can you make a request on the repository that aggregates information from that subgraph?
- Andrew Woods summarized that you need to include in your transform request that "Prefer" header that would be available in the ldpath query
- Regarding full support for ldpath syntax, the inverse lookups aren't supported.
- fcr:transform is a reformatting of what you can get from a get request
- Andrew Woods will document this on the wiki page
- Documentation
- Released 4.0 in November and it has its own documentation space (which has been locked)
- 4.x documentation space is a copy of that and should be the place where updates occur
- As part of the release, this is copied for that version documentation.
