Versions Compared

Old Version 2

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 3

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • General Updates (Tim)
    • Tentative release schedule for 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.
  • Angular Team Updates (Art)
    • Merged PRs: 
    • In Progress tickets / PRs:
      • Lotte working on the menus (based on mockups)
      • Kristoff creating & editing Communities, Collections & Items
    • Tickets / PRs requiring review:
      • Angular 6 PR (ready for early reviews, but won't be merged until Submission UI is merged) becoming a high priority: https://github.com/DSpace/dspace-angular/pull/320
      • Art noted that Angular 7 was just released this week. However, no rush to upgrade yet, as we'll need to wait on our dependencies to update to v7 compatibility
      • However, this notes that we really should work to get to Angular 6 soon (waiting on Submission PR still, see below)
      Tickets / PRs requiring review:
  • REST Team Updates
  • Discussion: What will be the Installation process for DSpace 7?
    • Keep installation of REST API & Angular separate?
    • Try to merge them (using a Mirage2 like approach) as suggested in blog posts like: https://medium.com/spektrakel-blog/angular-in-the-enterprise-building-angular-apps-through-maven-3ca535152f85 ?
    • 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
    • Art asks what about Solr?
      • 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)
      • Discussion on this begun at: Upgrading Solr Server for DSpace
      • Mark H. Wood and Terrence W Brady are taking a lead here.  Tim has helped on the Solr Client upgrade (nearly complete in this PRAlso a Solr upgrade in the works: https://github.com/DSpace/DSpace/pull/2058And a log4j upgrade in works: )
      • 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.
    • Discussion ran long...had to wrap up.  Next Steps:
      • Tim will re-investigate this approach and revamp/refactor the old PR (https://github.com/DSpace/DSpace/pull/22412231)
      • Others should think more on this, and report back if you have concerns (earlier the better, so we can choose a new direction, if needed)
      • Discussion to continue in coming weeks.
  • Development planning/updates in Development Planning Spreadsheet.  (Did not touch on today)
  • The Next Meeting will be Thursday, Nov 29 at 15:00UTC (10:00am EST) in DSpace Meeting Room
    • NOTE: Next Thursday (Nov 22) is a holiday in USA (Thanksgiving). Tim will be on holiday from Nov 21-23, returning on Monday, Nov 26.