Tentative release schedule for DSpace 7.0 (goals set by DSpace Leadership subgroup)
Quick updates on Angular UI tickets and/or PRs (Art)
Discussion: when do we schedule the Angular 6 upgrade?
Quick updates on REST API tickets and/or PRs (Andrea)
General Discussion Topics
DSpace 7 installation/customization process. Documenting our plan/goal for 7.0
Require separate installation/setup/prerequisites for REST API (backend) and Angular UI?
Somehow bundle the two together (and optionally let you install each separately)? There are options to build/bundle Angular apps via Maven (similar to the Mirage2 npm-based build process)
Also, how will we recommend customizing UI / themes?
(Notes below copied from last meeting. Details will be updated during this meeting.)
General Updates (Tim)
Tentative release schedule listed at DSpace 7.0 (goals set by DSpace Leadership subgroup)
Preview release in late Jan / early Feb. Key feature to show off here is Configurable Entities. This release won't have all DSpace 7 features, but is just a "first taste" with more features to come.
Beta in late April (tentative). Beta will be the first release that includes all DSpace 7 features.
Final in late May (tentative). Goal is to have this release prior to OR2019 (early June) if at all possible.
All deadlines are just goals. They seem doable right now, but we'll know how we are doing based on whether we can hit the first goal.
Our team goal is to get as much ready to merge by end of 2018. That ensures we have much of January to cleanup / bug fix existing features prior to the "Preview" release.
This ticket is also waiting on Tests/Specs to be implemented
Giuseppe will be dedicated to DSpace 7 as of November 20. Will have two weeks of effort coming to help fix up this PR. Giuseppe may also contribute on the REST API effort for Submission/Workflow too.
Mark noted that he's working on Java API backend for Curation Tasks. It'd be good to have anyone working on the REST API Curation Tasks endpoint look at the backend proposed changes in these PRs. (It's possible these backend changes could make the REST API implementation easier). Ben Bosmannoted he'd try to review these.
Art notes that Mirage2 process was always "clunky" and not ideal. Might be more problems than it's worth.
Mark notes that installing them separate may not be that bad as long as each part is easy to install on its own. Could we just ensure each piece is easier?
Tim notes that one way to simplify the install process of each part would be to improve on our backend (REST API) installation. We all know that it's "clunky" and not ideal
Mark asks which parts are "clunky"?
Tim's opinion is the multiple webapps are a problem. They make installation slightly more difficult (copying over multiple things into the right area). They also require more resources – each webapp loads up all DSpace JARS, initializes Hibernate & Flyway, etc. A lot of this is unnecessary.
Tim notes we could lean more on tools/processes provided by Spring Boot if we think of merging all our various webapps into one webapp
Solr is it's own problem. In DSpace 7, we must upgrade to a non-EOL version (Solr v6 or 7), which means Solr must become a prerequisite (no longer embedded in DSpace)
In any case, Solr is a separate issue, and it wouldn't be included in this "one webapp" idea.
Andrea is skeptical still. Notes that he likes the general direction of using Spring Boot tools, like turning DSpace into a runnable JAR (similar to how Solr now works). However, he's not sure about the benefits of one webapp approach. Also notes he likes managing Tomcat himself.
Tim notes that the one webapp approach is just the first step. We cannot get to a runnable JAR or even a "drop in" WAR until we find a way to deploy as one webapp
Whether we can get to a runnable JAR in DSpace 7 is still a question anyways. The approach right now is just to simplify our Maven processes, and rely more on Spring Boot build/deploy tools – that provides good benefits on its own. We can make the decision on a runnable JAR vs single WAR later.
Lieven notes this sounds good, but does Tim have time to build this?
Tim notes this is important for early adoption of DSpace 7. Effort of a single webapp doesn't seem too large (maybe a few days), and likely could be done over several weeks (shaving off time on Fri or Mon, which can be slower).
Obviously though, if the effort starts to look larger, we may need to delay this until Beta or Final release, or even post-7.0. Tim can keep everyone posted.