This Confluence wiki site, maintained by DuraSpace prior to the recent merger with LYRASIS, will transition from the duraspace.org domain to the lyrasis.org domain on Saturday, Nov 16 beginning at approximately 7pm ET. A period of downtime of 2-3 hours is expected. After the transition, this wiki will be available at https://wiki.lyrasis.org/. All links to duraspace.org wiki pages will be redirected to the correct lyrasis.org URL. If you have questions prior to or following the transition please contact: wikihelp@lyrasis.org.
Page tree
Skip to end of metadata
Go to start of metadata

A brief discussion took place regarding moving forward with the migration-utils, and preparing of tickets for some focused sprint work.

The following points were made:

  • authz migration should probably just entail moving over the XACML as is
  • the command line tool should use spring, and possible just be a spring boot application rather than a camel component
  • Ben could be convinced to work on service migration
  • discussion of audit log
    • much of this is redundant for versioned datastreams
    • migrate to premis?
    • wait for the audit service discussions to come up with something
  • we should use the same property name to preserve historic modifcation dates as the hydra effort
  • we should consider and design the interaction with the command line tool if that will be our ultimate goal

 

  • No labels

2 Comments

  1. the command line tool should use spring, and possible just be a spring boot application rather than a camel component

    Does the above statement imply that the migration-utils workflow will not tie into a camel flow?

  2. Unknown User (daniel-dgi)

    It's possible, depending on the status of a java fcrepo4 client library that's out there.  It came up as an option due to the fact that the main benefit of using camel would be the fcrepo-camel component, and if the client library was functional then spring's batch framework could also be used and the whole project could be kept as a single command line tool.  No decisions were made, however.

    I think if the other client lib is in a less finished state than the fcrepo-camel component, then that makes camel the winner.