Versions Compared

Key

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

...

  • Revisiting Discovery Discussion
    • Kevin Van De Velde volunteers to prototype Discovery + Elastic Search (as alternative backend to Solr). Will start up a JIRA issue & code on GitHub
  • Brief discussion on migration to GitHub
  • Detailed Discussion on Maven Project Consolidation
    • SWORD2 maven project uses a different format. Itdoesn't have sub-projects for '-api' and '-webapp'. Rather, uses the capabilities of Maven to build both JAR & WAR from a single Maven module:
    • Mark Diggory proposes we use this as a "model" Maven Project.
    • Question #1: Do we want to reorganize existing Maven projects (XMLUI, JSPUI, LNI, OAI, etc) to consolidate the "-api" and "-webapp" projects?
      • Some general questions about how this would affect user customizations and/or "vendor drops".
        • NOTE: Should not affect anyone using Overlays.
      • We would need to make this change clear (Documentation).
      • Also would need to ensure it doesn't affect our IDEs / Development environments (we doubt it, but needs further investigation)
      • In general, most seem in favor of idea & feel it could be a simplification of our codebase.
    • Next Steps (for Question #1)
      1. This new Maven project organization structure should be documented! Likely under Documentation section on Advanced Customisation
      2. Try out this reorganization for one of the main modules (e.g. XMLUI) and ensure IDEs are not affected
    • Question #2: What about Maven projects like Discovery? http://scm.dspace.org/svn/repo/dspace/trunk/dspace-discovery/
      • Technically the "-provider" part likely may belong alongside the 'dspace-api' (in some way). In addition, the "-xmlui" parts likely should belong alongside the "dspace-xmlui".
      • This question seems directly related to whether Discovery is the "default" or the only option for Browse/Search.
      • But, in some ways, it would also help to simplify the codebase – less maven projects = less confusion. It also makes sense to consolidate all things related to XMLUI under "dspace-xmlui".
      • Wasn't a real conclusion on this question.
  • Stepping Back: Larger reorganization questions posed
    • Should Search/Browse even be part of 'dspace-api'? Technically they are more UI related?
    • Should we be taking a step back and conceptually thinking about what are the "pieces" of DSpace? Some possible "pieces" include:
      • Content Model piece
      • Search/Browse mechanism
      • Event Manager (to pass events between pieces)
      • One or more UIs
    • Where does the "Business Logic API" conceptually fit into these "pieces"? Can better defining these pieces help us to better draw the lines between "Business Logic API", REST API , Content Model, UI?
    • Some reflection back on the DSpace 2.0 thought exercises/prototype from 3 years ago.
    • Should we think about having a similar conceptual thought exercise with the current Committers Team (and reflect back/pull from DSpace 2.0 where it still makes sense)?
      • Idea to try and start this thought exercise tomorrow, using an online whiteboard like Dabbleboard
  • Feeback on Virtual Summit
    • Tim would like feedback on how this Virtual Summit has gone.
      • Has it been worthwhile to you?
      • Should we do this again? (e.g. every 6 months? every year?)
      • Is the timeframe about right? One week of meetings, with about 1-1.5 hours per day (most days we've ended at about 1 hr 15 mins)?

Wiki Markup
We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=2012-03-01
Image Removed
 (Starts at \[20:01\])