...
- OSGi, this is not some much making Fedora core fully runnable in OSGi, but getting us on a path to it. Currently we publish all Fc4 artifacts as OSGi bundles. The problem is it defines what packages it exports and imports.
- The problem is these Fc4 hacks in fedora-impl, there are some internal classes in the modeshape layer that are being hacked in to making changes. So Fedora is importing and exporting the same packages. It works in terms of war deployment.
- But removing this should be a priority, and it requires some understanding of how to do it.
- There might be a way to approach Modeshape to make some of these changes, also try to use some of the public methods to do the same things we are doing.
- Other than package invasions, is standard practice with OSGi that has internal classes that are not exported. The Maven bundle plugin with take any class that has impl in the package and excludes it, making it non-exported. Perhaps rename some of these packages to get around this. kernel -> kernel-api and kernel-impl -> kernel. Same thing with the other impl packages. Do the modeshape hacks we have "need" to be exported? As far as we know they do, but someone with more experience might be able to do that.
- That is for building them as proper OSGi bundles, the next is being able to hot-deploy extension modules. We would have to think that through.
- What would be the benefit of hot-deployment? If you have a Fc4 instance and there is a new module, and you want that to run inside Tomcat then you could be required to re-compile the entire application and restart the container. Webapp-plus with different configurations as an example of how we are doing this now. OSGi is just allowing you to deploy vanilla fedora and then add/remove any feature module without having to re-compile or cycle the container.
- Seems like a good way to facilitate bug reporting, to be able to test use-cases with a vanilla configuration. Imagine different profiles that could be deployed.
- What is the effort OSGi?
- packaging and deploying with Modeshape could be complicated. Unknown User (acoburn) has made attempts but has been unable to resolve it so far. Better understanding the invasion of modeshape namespace in Fedora 4 namespace.
- RDF libraries - in the fc4 core we are using 2 different libraries (Jena and Sesame) in fcrepo-camel using Clarrisa. RDF is central to the idea of Fedora, but we are not doing a lot of complex RDF operations.
- There is a project called commons-rdf (Apache), very early. It defines an interface (Java 8) using Java 8 streaming api. Jena and Sesame are moving towards that. We should look at using this in fc4 core instead of specific Jena and or Sesame classes. There are implementations from Jena, Sesame and Marmotta. (A. Soroka: There is definitely not an impl from Jena, yet, although the Jena project is thinking hard about how to do one. Nor, to my knowledge, has Sesame produced one. See here for current known implementations.)
- Consolidate our RDF libraries for good reasons. We should keep an eye on this project as it could help us. We could get into the discussion, not much room for influence. More that these RDF libraries need to implement the new commons-rdf api. Will this commons-rdf API will meet all our needs? Not sure currently.
- Skipping dependency chain in Java 8.
...