Task #5820
closed
The biggest obstacle to integrating D1 code directly is decoupling from Spring. Thankfully a lot of it is just name-value stuff, so at least the basic mapping of metadata format elements to SOLR structures can be extracted from configuration information (either build or run time).
After some investigation, it wouldn't be that hard to get the full stack working with but... it kind of amounts to just building a scaffold that imitates Spring. Currently aiming to pull out just the SolrField information from the various metadata contexts, at run time via XPath if it's not too ugly, into a document definition of a sort. This should permit using at least the various Field and Converter classes while keeping in sync with the CN indexing.
Ideally we can compromise between reusing existing DataONE indexing configuration and making it easy for Metacat administrators to edit and/or augment Metacat indexing configuration.
Spring configuration requires admins to have a "spring mindset" which might be difficult for some of our usual audience. But it would be great to reuse the properties and supporting bean classes from DataONE indexing so that there's a solid starting point.
I want to point out that while we do want to support all the DataONE indexing features, we also have to opportunity to make those features better and more easily used. After all, we are developing "Metacat indexing" and should design it with care.
Original Bugzilla ID was 5820
- Assignee changed from Brendan Hahn to Jing Tao
We decided to use - wholesale - the existing DataONE index configuration component even though it uses Spring. It will be deployed as a stand-alone web application listening to events in Metacat. That way we avoid having Spring within the Metacat code base.
- Status changed from New to Resolved
Create metacat-index web apps to avoid the spring in the metacat. We also create the metacat-common to share code between metacat and metacat-index.
Also available in: Atom
PDF