|
|
|
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
|
|
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
|
|
|
+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+Service+based+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+Voting+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
|
|
|
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. ------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
|
|
|
+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+Service+based+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+Voting+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
|
|
|
+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
|
|
|
+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+Service+based+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+Voting+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
|
|
|
+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+Service+based+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+Voting+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
|
|
|
+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
|
|
|
+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+apiWhat 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
|
|
Administrator
|
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
|
|
|
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
|
|
|
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
|
|
Administrator
|
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).
- 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.
- 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
- 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.
- 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
- 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.
- We will quickly review each module's PR as it comes in, and
merge it as soon as possible thereafter.
- 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.
- 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)
- 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
|
|
Locked
signature.asc (188 bytes)