PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Tim Donohue
Administrator
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Tim Donohue
Administrator
I vote +1

- Tim

On 8/6/2015 9:47 AM, Tim Donohue wrote:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org


------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Brian Freels-Stendel
In reply to this post by Tim Donohue

+1

 

It'll be a smaller job now than later, and the benefits are significant.

 

B--

 

From: Tim Donohue [mailto:[hidden email]]
Sent: Thursday, August 6, 2015 8:48 AM
To: [hidden email]
Subject: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

 

Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:

+1 = "I agree. We should include Services API refactoring in 6.0"

 0  = "I'm undecided / unsure" (Please provide a reason)

-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)

Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: <a href="https://wiki.duraspace.org/display/DSPACE/DSpace&#43;Service&#43;based&#43;api">https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?

  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.

PROS to adding to 6.0:

  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).


[1] <a href="https://wiki.duraspace.org/display/DSPACE/Developer&#43;Voting&#43;Procedures"> https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap

-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Bram Luyten-3
In reply to this post by Tim Donohue
+1

Bram

-- 
logo 
Bram Luyten 
250 Lucius Gordon Drive, Suite B-3A, West Henrietta, NY 14586
Esperantolaan 4, Heverlee 3001, Belgium
www.atmire.com 

On 6 August 2015 at 16:50, Tim Donohue <[hidden email]> wrote:
I vote +1

- Tim


On 8/6/2015 9:47 AM, Tim Donohue wrote:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org


------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel



------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Peter Dietz-2
I am happy to have an ORM added. I'm not really a fan of adding <Class>DAO, <Class>Service, <Class>ServiceImpl for each class, it feels verbose, but I guess it separates concerns. My coworkers' experience with Hibernate is that it does 90% of things well, but the remaining 10% is a major pain. Code where you thought you were making 1 query turns into thousands of queries. I'd like to see some performance comparisons between our native SQL, and hibernate's execution plan. Hibernate's caching and lazy-loading sound like improvements though.

I'm supportive, I'll dig in, to see if I find any deal breakers.

________________
Peter Dietz
Longsight
www.longsight.com
[hidden email]
p: 740-599-5005 x809

On Thu, Aug 6, 2015 at 11:20 AM, Bram Luyten <[hidden email]> wrote:
+1

Bram

-- 
logo 
Bram Luyten 
250 Lucius Gordon Drive, Suite B-3A, West Henrietta, NY 14586
Esperantolaan 4, Heverlee 3001, Belgium
www.atmire.com 

On 6 August 2015 at 16:50, Tim Donohue <[hidden email]> wrote:
I vote +1

- Tim


On 8/6/2015 9:47 AM, Tim Donohue wrote:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org


------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel



------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel



------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Becker, Pascal-Nicolas
In reply to this post by Tim Donohue

+1

  Pascal

 

From: Tim Donohue [mailto:[hidden email]]
Sent: Thursday, August 06, 2015 4:48 PM
To: [hidden email]
Subject: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

 

Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:

+1 = "I agree. We should include Services API refactoring in 6.0"

 0  = "I'm undecided / unsure" (Please provide a reason)

-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)

Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: <a href="https://wiki.duraspace.org/display/DSPACE/DSpace&#43;Service&#43;based&#43;api">https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?

  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.

PROS to adding to 6.0:

  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).


[1] <a href="https://wiki.duraspace.org/display/DSPACE/Developer&#43;Voting&#43;Procedures"> https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap

-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Robbins, Seth David
In reply to this post by Tim Donohue
+1
I’ve already worked with jpa/Hibernate a bit in our Vireo ETD submission system, and I definitely think the pros outweigh the cons.
It’s exciting to see this going forward.
--Seth

From: Tim Donohue <[hidden email]>
Organization: DuraSpace
Date: Thursday, August 6, 2015 at 9:47 AM
To: "[hidden email]" <[hidden email]>
Subject: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Pottinger, Hardy J.-2
In reply to this post by Tim Donohue
+1

--Hardy


From: Tim Donohue [[hidden email]]
Sent: Thursday, August 06, 2015 9:47 AM
To: [hidden email]
Subject: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: <a class="moz-txt-link-freetext" href="https://wiki.duraspace.org/display/DSPACE/DSpace&#43;Service&#43;based&#43;api" target="_blank"> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] <a class="moz-txt-link-freetext" href="https://wiki.duraspace.org/display/DSPACE/Developer&#43;Voting&#43;Procedures" target="_blank"> https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Kim Shepherd-2
In reply to this post by Tim Donohue
On 7 August 2015 at 02:47, Tim Donohue <[hidden email]> wrote:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  

+1

T: @kimshepherd
P: +6421883635

0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC
https://keybase.io/kshepherd
 


------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

KNOWLES Claire-2
In reply to this post by Tim Donohue
+1

--
Claire Knowles
Library Digital Development Manager
Library and University Collections, Information Services
University of Edinburgh



From: Tim Donohue <[hidden email]>
Organization: DuraSpace
Date: Thursday, 6 August 2015 15:47
To: "[hidden email]" <[hidden email]>
Subject: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: <a class="moz-txt-link-freetext" href="https://wiki.duraspace.org/display/DSPACE/DSpace&#43;Service&#43;based&#43;api"> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] <a class="moz-txt-link-freetext" href="https://wiki.duraspace.org/display/DSPACE/Developer&#43;Voting&#43;Procedures"> https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Mark H. Wood
In reply to this post by Tim Donohue
+1

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Terry Brady-2
In reply to this post by Tim Donohue
+1

On Thu, Aug 6, 2015 at 7:47 AM, Tim Donohue <[hidden email]> wrote:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel




--
Terry Brady
Applications Programmer Analyst
Georgetown University Library Information Technology
425-298-5498 (Seattle, WA)

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

TAYLOR Robin
In reply to this post by Tim Donohue
+1

This is all good practice, industry standard stuff that we probably should have done ages ago, so well done to the @Mire guys for pushing it forward.

Cheers.
 
Robin Taylor
Main Library
University of Edinburgh



From: Tim Donohue <[hidden email]>
Sent: 06 August 2015 15:47
To: [hidden email]
Subject: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0
 
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd  appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
  0  = "I'm undecided / unsure" (Please provide a reason)
 -1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
 Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which  is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts  to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain,  more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at:  https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
 This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.  Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.

We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will  need similar refactoring as soon as possible.

 
If this refactor is voted in, Committers will immediately do the following:  The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)

We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 

We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)

Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.

 
 PROS to adding to 6.0:
 It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)

It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL  or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries  are delegated to Hibernate).

It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be  difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or  more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.

As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked  above) showing how to perform common tasks via the new API.

As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).


[1]  https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2]  https://wiki.duraspace.org/display/DSPACE/RoadMap
--  Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org    
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Tim Donohue
Administrator
In reply to this post by Tim Donohue
Hi all,

Just a friendly reminder to submit your VOTE before our Developers Meeting on Weds at 15:00 UTC!  Just respond to this thread.

By my count, here are our current totals:
+1 votes:  8 Committers, 5 Community Members
 0  votes:  0 people
-1  votes:  0 people
Thanks all!

Tim

On 8/6/2015 9:47 AM, Tim Donohue wrote:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)

Please VOTE with one of these three options:
+1 = "I agree. We should include Services API refactoring in 6.0"
 0  = "I'm undecided / unsure" (Please provide a reason)
-1  = "I disagree. The Services API refactoring should NOT be included in 6.0"  (Please provide a reason why you disagree)
Per our Voting Procedures [1], a vote on code modifications requires: "at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'."  While anyone is welcome to vote, only Committers have "binding" votes (and can cast a veto).  Others are free to vote to express your opinion, but those votes are considered advisory in nature.

This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting).

If there are any questions, feel free to ask them on this thread.


Summary of Services API refactoring

The Services API refactoring is a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Services API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org).  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api

What does adding this refactor to 6.0 mean?
  • This is essentially a *new* Java API for DSpace.  But, it performs a very important refactor (see "Pros" below).
  • It is not backwards compatible with the existing API.  All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API.
    • Committers will be expected to learn, use and support this API immediately.  @mire will be providing additional training materials / examples to help everyone get up to speed.
    • We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace.  Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible.
  • If this refactor is voted in, Committers will immediately do the following:
    • The "master" branch will be temporarily frozen. We'll ask for no new changes until this API can be merged (PRs can still be created, but we will refrain from merging them)
    • We'll start a new (temporary) feature branch (under DSpace/DSpace) based of latest "master" and merge the existing Services API code there. 
    • We'll then rapidly work together to refactor and test all other modules based on the new API. (If we work as a team, the goal would be for this process to only take a few weeks)
    • Once everything is refactored against this API and passes our Unit Tests, the Services API code will be merged into "master". At this point, "master" will be unfrozen, and we can again merge in PRs for the 6.0 release.
PROS to adding to 6.0:
  • It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap [2] (especially, moving us towards potentially better support of third-party modules)
  • It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
  • It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
  • The API itself will not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.

CONS:

  • It is not backwards compatible with the existing Java API.  Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.
  • As it is not backwards compatible, this does mean that existing PRs (Pull Requests) reliant on the Java API may need refactoring/rebasing.  Unfortunately there's no easy way around this, but examples already exist in the documentation (see wiki page linked above) showing how to perform common tasks via the new API.
  • As this is a major change, it could affect our 6.0 timelines unless we can work together to quickly get this change merged and tested.  The quicker the merge process occurs, the more rapidly we can stabilize everything (and refactor existing PRs as needed).

[1] https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[2] https://wiki.duraspace.org/display/DSPACE/RoadMap
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org


------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

Andrea Schweer-2
In reply to this post by Tim Donohue
On 07/08/15 02:47, Tim Donohue wrote:
As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.

+1

cheers,
Andrea

-- 
Dr Andrea Schweer
IRR Technical Specialist, ITS Information Systems
The University of Waikato, Hamilton, New Zealand

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Re: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0

a.bollini
In reply to this post by Tim Donohue
Il 06/08/2015 16:47, Tim Donohue ha scritto:
Hi Developers / Committers,

As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release.  As this change constitutes a major code refactor of the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0.  (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email)
+1

It is an important step forward to the necessary modernization of the DSpace sourcecode. We at Cineca envision that this step will help DSpace to proceed faster.
We think that it is better to make this change immediately in 6.0 to avoid a strong overlapping with the new single UI project.
I can also anticipate that we will help as required to move the JSPUI module and the DSpace-CRIS extension to the new business layer.
Best,
Andrea




-- 
Andrea Bollini
International Business Development, Deputy Leader
Open Source & Open Standards Strategy, Head
Cineca

Via dei Tizii, 6
00185 Roma, Italy
tel. +39 06 44 486 087 - mob. +39 348 82 77 525
http://www.cineca.it 

------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Reply | Threaded
Open this post in threaded view
|

Services API adoption in 6.0 (Was: PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0)

Tim Donohue
Administrator
In reply to this post by Tim Donohue
Hi all,

This vote is officially closed.  It PASSED by a final vote of:
+1 votes:  10 Committers, 5 Community Members
 0  votes:  0 people
-1  votes:  0 people
This means that in the coming weeks we will be working to adopt/merge the Service-based API code into our "master" branch in preparation for the 6.0 release.

In today's developers meeting [1], we decided on exactly how we plan to get this code merged as soon as possible (so that we can stabilize our codebase and any affected, pre-existing Pull Requests).
  1. Effective immediately, the DSpace "master" branch is considered under a "soft freeze".  This means that, while we will still accept PRs, no PRs will be merged until after the Service-based API refactor. However, we will make exceptions for security issues or other time-sensitive issues.
  2. A "feature branch" was just created where the majority of the initial stabilization work will take place.  https://github.com/DSpace/DSpace/tree/DS-2701-service-api
  3. By next Weds, Kevin Van De Velde will submit the first PR against that new "DS-2701-service-api" branch. This initial PR will include the API refactor and XMLUI refactor ONLY.  We will review and merge it as soon as it's available. Kevin will also provide detailed documentation/examples.
  4. We are searching for volunteers to help us *quickly* refactor all other DSpace modules. I've started a TO-DO list (see yellow note) on this page. Please SIGN UP if you'd like to help: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
  5. Volunteers will claim one (or more) modules to refactor. They must create a PR *against* the "DS-2701-service-api" branch.  A module will be considered "fixed" when it successfully compiles (against the new API) and all its unit tests (if any) pass.
  6. We will quickly review each module's PR as it comes in, and merge it as soon as possible thereafter.
  7. Once all modules have been fixed (i.e. they all compile), we'll merge the "DS-2701-service-api" branch into "master", and proceed with more detailed (manual) testing of all modules/features to find any immediate bugs.
  8. At that point, the "soft freeze" of master will be removed.  We hope this ENTIRE process will take no more than 2 weeks (assuming we can find enough volunteers to help out)
  9. Once "master" is updated with the newly refactored API, all open Pull Requests will need to be re-reviewed.  Unfortunately, some/many PRs may no longer be mergeable and may need rebasing/refactoring to work with the new API.

If there are any questions or comments on this process, please feel free to ask on this mailing list.

Thanks!

Tim Donohue

[1] DevMtg logs: http://irclogs.duraspace.org/index.php?date=2015-08-12



------------------------------------------------------------------------------

_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel